Cream of the Crop 20

home *** CD-ROM | disk | FTP | other *** search

/ Cream of the Crop 20 / Cream of the Crop 20 (Terry Blount) (1996).iso / bbs / brv1_b6.zip / BASERUN.DOC next >

Wrap

Text File | 1996-06-02 | 264KB | 5,814 lines

┌─────┐ ┌──────┐ ┌───────┐ ┌─────┐ ┌─┐ ┌─┐ ┌──────┐ ┌──────┐ ┌─────┐ ┌──────┐ │ ┌─┐ │ │ ┌──┐ │ │ ┌┐ ┌┐ │ │ ┌─┐ │ │ │ │ │ └┐ ┌─┐ │ │ ┌──┐ │ └─┐ ┌─┘ │ ┌──┐ │ │ │ └─┘ │ │ │ │ │ ││ ││ │ │ └─┘ │ │ │ │ │ │ │ │ │ │ └──┘ │ │ │ │ └──┘ │ │ │ ┌─┐ │ │ │ │ │ │└─┘│ │ │ ┌───┘ │ │ │ │ │ │ │ │ │ ┌──┐ │ │ │ │ ┌──┐ │ │ └─┘ │ │ └──┘ │ │ │ │ │ │ │ │ └─┘ │ ┌┘ └─┘ │ │ │ │ │ │ │ │ │ │ │ └─────┘ └──────┘ └─┘ └─┘ └─┘ └─────┘ └──────┘ └─┘ └─┘ └─┘ └─┘ └─┘ ┌─────┐ ┌─┐ ┌─┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌───────┐ ┌─────┐ │ ┌───┘ │ │ │ │ │ ┌───┘ └─┐ ┌─┘ │ ┌───┘ │ ┌┐ ┌┐ │ │ ┌───┘ │ └───┐ │ └─┘ │ │ └───┐ │ │ │ └─┐ │ ││ ││ │ │ └───┐ └───┐ │ └─┐ ┌─┘ └───┐ │ │ │ │ ┌─┘ │ │└─┘│ │ └───┐ │ ┌───┘ │ │ │ ┌───┘ │ │ │ │ └───┐ │ │ │ │ ┌───┘ │ └─────┘ └─┘ └─────┘ └─┘ └─────┘ └─┘ └─┘ └─────┘ Base Runner, v1.o, Written by Steve Tupy Copyright (C)1994-96 CompuData Systems All Rights Reserved ───────────────────────────────────────────────────────────────── WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING ───────────────────────────────────────────────────────────────── This program is NOT FREE. We support the shareware concept in allowing you to try this program out , but FULLY expect you to support us in making this program everything it can be. This is something that CANNOT be done if you do not register the programs you use! This is NOT an option! You are entitled to evaluate this program for not more than 30 days at which time you are expected to either delete it from your system(s) or register it. ───────────────────────────────────────────────────────────────── Table of Contents ───────════────── Introduction to Base Runner features,echos,filebases,dist. package etc. 1.1.0 How does it work? 1.1.1 Describing Base Runners Filebase system Layout,indexes,handling etc. 1.1.2 Describing concepts of File Ownership 1.1.3 What does it do? Read Config, File Manager,Echo importation, deletions, adoptions, file movement, duplicate checking etc. 1.1.4 Other Considerations 1.1.5 File Area Links 1.1.6 System Requirements 1.1.7 Main Configuration 1.2.0 Paths,System Info,Global Options. 1.2.1 Inbound Directory, Outbound Directory, Netmail Directory, Alternate Netmail Directory, Filebase Directory, Headers, Log File, Master File List, Hatch Master List to?, File Trash Can, Node Address Trash Can, Uplink List Directory, Work Directory, External Text Editor, Magic File List, CD ROM Drive List. Global Options 1.2.2 BBS Name, Sysop Name, BBS Phone, Location, File Manager, Duplicates to Bad Directory, Duplicate Limits, User Uploads, Auto Uplink, File System, History Days, HTML Style bulletin generation, Video mode, Time Zone, Net Retry, Retry Delay, Text List, PCB Netmail or *.MSG, Auto Hatch, Screen Blanker, Minimum Drive Space, Log Format. Network Address' 1.2.3 Origin Lines 1.2.4 Virus Scanners 1.2.5 Compression Formats 1.2.6 Extension, Stamp Offset, Recursable?, Extract1 Command line, Extract2 Command line, Add File(s), Delete File(s), Archive Comment, Archive Conversion, Archive Stamp. File Folders 1.2.7 BrConfig DataBases 1.2.8 Node Information 1.2.9 Uplink Lists, Auto Area Creation, Auto Unlinking, Addressing, Sysop, File Manager Password, Folders, Attach Flag, Auto Create?, Cloning File Areas, Cloning Echo Areas, Security, Request to Message Base, Kilobytes In, Kilobytes Out, Files In, Files Out, Daily KByte Cap, Daily File Cap, Unlinking, File Manager Name, Area Manager Netmail Status, Maximum downlink archive size, Advanced Tic, Ticmode, Archive Compression type. File Area Configuration 1.2.10 File Area Name, File Area Description, File Directory, BBS File Base, Filebase Name, Folders for this area, User Uploading into System, BBS Header, BBS Footer, Add Files, Delete Files, Zip Comments, Maximum Files, Delete Age, Archive Conversion, Virus Scanning, Duplicate Checks, Deletions, Adoptions, Uploads, File Requestable, System Wide Dupes, Original Dates, High Ascii, Sort By, Sort Order, Convert to, Security. Importing from your PCB files areas 1.2.11 File Area Links 1.2.12 Custom Headers/Footers 1.2.13 Alt-G, File Areas Global Menu 1.2.14 Echo Area Configuration 1.2.15 Area Name, Comment, Folder, Message Base, Announcements, Uploaded By, Aka's, Initial, Owner, Pass Thru, Echo Out, Description Options, Origin Line, Keep Requests, Keep Receipts, Announce, Traffic, Files In, Files Out, Bytes In, Bytes Out, Hatched Files, Hatched Bytes, Delete Tic File, Delete Attach File, No Delete, Alt-G, Echo Areas Global Menu 1.2.16 A Note About Downlinking(Unlimited Downlinks) 1.2.17 Downlink and Hatching 1.3.0 Using BRConfig 1.3.1 BRUtil Utility Program 1.4.0 Using BRUtil Pack FileBases, 1.4.1 Build Indexes, 1.4.2 Duplicates, 1.4.4 Dupe Trim, 1.4.5 Notify Lists, 1.4.6 Hatching Files, 1.4.7 Sending Files, 1.4.8 Init Bases, 1.4.9 Build CRC, 1.4.10 Auto Unlinking, 1.4.12 About Base Runner, 1.4.13 History+ 1.4.14 Dirs(DIR & Files.BBs Writes) 1.4.15 Exit to Dos 1.4.16 BREdit Filebase Editor 1.5.0 Requirements, 1.5.1 Initial List Dialog, Command Summary 1.5.2 "Hot Spots", Alt A - Add to File Id, Abandoning Files, Copying Files, Deleting Files, Editing Files, File id file add, File Hatching, Area Info, No Kill, Moving Files, No Show, File Ownership, Selecting Files, Touching Filedates, Viewing Files, Exiting the program instantly, Other Commands available. Editing A File Entry. 1.5.3 BRFreq, Base Runners File Requesting System 1.6.0 Introduction Description of what it does Installation and Setup 1.6.1 Configuration 1.6.2 Path to Intro Screen Path to Main Screen Path to Bye Screen Path to Help Screen Screen Delays Using BRFreq 1.6.3 Batch Editor, System Selection, Goodbye/Logoff, Files Listings, Help, Quit to BBS, Other considerations. 1.6.4 Requests from Other Systems. Using Base Runner 1.7.0 Using the Area Manager 1.7.1 What went wrong? 1.7.2 Converting from Other Formats(Convert.exe) 1.7.3 What you get for registering. 1.7.4 ErrorLevels returned by Base Runner 1.7.5 Why use Base Runner? 1.7.6 Strategy 1.8.0 More Points Regarding File Movement 1.8.1 A Couple of Tricks. 1.8.2 User Support and Support Sites 1.9.0 Lets hear it for our Beta Team! 2.0.0 Files in the distribution archive 2.0.1 DataBase files maintained by Base Runner 2.0.2 1.1.0 Introduction ------------ Base Runner is a utility designed to completely self-maintain every possible aspect of your PCBoard(or FILES.BBS) file system. It does everything. And when I say everything, I mean EVERYTHING. The program and its utilities cover such a broad range of features that it is not advised that you just plug it in and walk away. For brevity, any reference to Pcb DIR files can also be considerd a reference to the commonly used FILES.BBS files that are used by most BBS systems for their file area lists. However, we designed it so that if there are certain features you don't want to run, you can disable them easily enough. For example, Base Runner covers all aspects of upload processing; compression conversion, virus checking and so on. But if you want to stick with your current upload processor then you can disable any or all upload processing procedures as you choose. Base Runner also fully covers anything to do with file echoes. If you don't know what file echoes are there is a section outlining them.In order to run the basics of Base Runner all you need is PCBoard v14.x. If you want to run file echoes you'll need a front end mail program like Front Door or D'Bridge and now PCB even supports Fido mail processing. And to even go further, Base Runner has a complete file request- ing system which allows both your users a very handy door to use to send requests back and forth between your system and others, and also other Fido sysops who may be connected to your requesting system as well. The door maintains batch ques, allows browsing the file areas of various systems while being able simply "Flag" files for requesting. Then the door automatically sends out the request to the appropriate system. All of this with full accounting of all file activity as well as configurable "Caps"(limits) on a node per node basis. It is also assumed that you know how PCBoard operates. As a matter of fact you should be WELL versed on how the PCBoard file system works; DIR files and so on. Like I said this is not a plug and play utility. It will require some thought as to how you set the system up. But once set up, the amount of time you'll spend maintaining your file system will be almost zero. No matter how a file enters your file system Base Runner will know about it and look after it for you. So what does it do.Since the scope of Base Runner is so large, it is best to first describe how it operates and the basic principles behind its operation and that's what we'll get into right off. 1.1.1 How does it work? ----------------- First, think of how your PCBoard file system works. You have a number of sub-directories with files in them for download by users. The main central reference to these files are the PCBoard DIR files; the text files that hold the file names, dates, sizes and descriptions. When using PCBFiler to manage your file areas, the DIR files are the main reference to the contents of each file area. Base Runner changes this outlook. When you install Base Runner, you run a procedure that reads all of your PCBoard DIR files and creates a set of databases that reflect their contents. As of this point, your DIR files are NOT the central reference to your file areas.The Base Runner databases now are. This makes PCBFiler obsolete. You won't use it anymore. Instead, you'll use the included utility, Bredit. It performs the same functions as PCBFiler plus many more. We knew it might be painful giving up PCBFiler so we had to provide something better; and we did. For FILES.BBS systems, this now offers a new editor for your use that will allow you to move,copy,delete,touch,view,hatch or do various other operations on your file areas. When Base Runner goes through its processes, the last thing it does is write an entirely new set of DIR files based on what's in the Base Runner databases. (filebases we'll call them) So now, a file area can be described as something that contains 3 elements: A sub-directory with files in it. A filebase (Base Runner database) as a central reference. A PCBoard DIR file(or FILES.BBS) The PCBoard DIR files are now a reflection of the Base Runner system. By now you're probably thinking, "But how do I look after <blank> now?". You don't. Base Runner does. Your DIR(or FILES.BBS) files are regenerated any time you run Base Runner. If you change them manually, any changes made with an outside utility will be lost. This is why Base Runner does everything you can think of. If nothing else can touch your file system then Base Runner had better be good! And it is. 1.1.2 FileBases --------- In order to better understand how to maintain your filebases, it's best to understand just how filebases work. In main configuration you give each file area the filename of the filebase. For example, say you have a file area called New Uploads. You might name the filebase "NEWUP". In this case, Base Runner will create: NEWUP.IDX - Filebase index FILEBASEDIR\IDX\NEWUP.IDX NEWUP.HDR - Filebase data header FILEBASEDIR\HDR\NEWUP.HDR NEWUP.TXT - Filebase text FILEBASEDIR\TXT\NEWUP.TXT The following is what is contained in each of these files: NEWUP.IDX: Filename - Name of a given file Filedate - Date of a given file Status - Status; deleted, etc. Offset - Where in NEWUP.FBS the main information starts NEWUP.HDR: Areaname - Name of the file area to which this file belongs Filename - Filename of this file Size - Size in bytes of this file Date - Date of this file Index - Where the file description starts for this file Length - Length in bytes of the file description CRC - CRC32 of this file ID - An identifying marker to aid in synchronization of corrupted filebases. Uploader - Person who uploaded this file. UL Date - Date of upload(if uploaded) of this file. Times DL - How many times has this file been downloaded. Last DL - Last date of download of this file(for future use). NEWUP.TXT: Line per line, not wider than 45 characters in PCB mode and not more than 60 characters in FILES.BBS mode, the text that goes into the description. There is one record for every file in both the IDX and HDR file. So if your new upload area has 200 files in it, each of these files will have 200 records. Each record contains the same information as your PCBoard DIR file(s) plus a bit more. You don't have to worry about the exact structure here, just the basics of what's involved. So what Base Runner does is maintains these databases, and the files associated with each record in the database. If a file shows up in a file area that Base Runner doesn't know about, Base Runner adopts the file and all of the above information automatically.If you kill a file off manually,Base Runner removes the record. When Base Runner processes a file area it loads the index file into memory entirely. This is a very small index record (only 23 bytes) and since all available memory is used, the only limit to the size of your databases is your available memory. Please note though, that a comparitive ratio IS held in conventional(the indexes are also indexed in a manner of speaking) memory, so you will see SOME conventional memory loss in VERY large filebases. Because it loads the entire index into memory, Base Runner is unbelievably fast considering what it does. If you enable every feature there is, basic maintenance takes seconds on even the largest area. How this is done is as follows. Only 20 bytes of the index are loaded at any one time. For each record, 2 bytes are held in what is known as conventional memory, memory below 1 meg, and the rest are thrown into pages in upper or extended memory if such memory exists. Failing that, conventional memory is used. Even if you are using total conventional memory of one meg you can load up a database of approximately 35,000 records per area. Assuming that this is attached to one DOS directory and that all the files are in that directory, DOS would break before Base Runner would. This kind of power is hard to come by these days. It may seem complicated but the complexity is handled by Base Runner. You now know roughly how the databases are managed and that's all you really need to know as far as the details go. The rest is configuration. You should also start to consider this new "view" of having seperate files areas and echo areas as this whole package revolves around those two levels of operation and their interaction with each other. 1.1.3 Ownership --------- As you may have noticed in the previous section, a filebase record holds the name of the file area to which a given file belongs. This is referred to as file ownership. In other words, when looking at a given file, that field answers the question "to which file area does this file belong?". When you configure your file areas (which we'll get into shortly) each file area must have a unique name. You pick the name, it doesn't matter what it's called. But something notable would help like NEW_UPLOADS or NEWUP90 or IBM_GAMES. As long as it's one word and is unique. Base Runner supports fully qualified automatic file movement. Each individual file on your system knows what area it's owned by or belongs to, even if it's in a different area. So although CHESS.ZIP may reside in NEW_UPLOADS, it actually belongs to, or is owned by IBM_GAMES. You can configure each file area to move the files it contains based on a number of days. For example, you could have NEW_UPLOADS move any files older than 30 days somewhere else. But where? Base Runner gives you 3 options. One is "Nowhere".Files stay in a given area for good. The second is to any other defined file area. The third is "Home". If a file area is set to move files Home after XX days, files older than XX days are moved to the area that owns them. A new upload area is perfect for this because any files older than the number of days you specify are moved to where they belong automatically. Needless to say, considerable thought should go into how your files system is configured. Like where you would normally move files manually. Base Runner was designed for maximum flexibility when it comes to how file areas are handled. User uploads are detected and imported automatically. If you want an off-line area, create one and tell all your files areas to move files there after 6 months or a year old. So when initially configuring Base Runner, keep this in mind because it's a crucial part of how Base Runner operates and how it will manage your system. The other included utilities provide maintenance and manual control over ownership also. If you would like some input as to how some of us(the beta team) have had it set up, please consult the document STRATEGY.DOC. 1.1.4 What Does It Do? ---------------- You'll get a better understanding of what Base Runner does from a list of its operational order. Remember that the things listed below are fully documented later on and that most of the individual functions listed here can be disabled or changed in configuration or from the command line. - Automatically Maintains Your Uplinks Lists ------------------------------------------ Early on in Base Runners execution, your inbound area is scanned for a match against your uplink lists, if any, in your nodes configuration to see if one of the files listed in your nodes base matches a file that is currently in your inbound directory. If a match is found, we assume it is a newly updated uplink list and we copy it to the uplink list directory configured in BRCONFIG. It is logged and reported to the screen. This way you are always up to date with your uplink lists and never have to maintain or "copy them" over to your Base Runner uplink list directory. These lists are used for your downlinks when they try to request echo areas from you that you don't currently have online. Your copy of Base Runner will scan these lists and if the uplink is connected to the same Folder(or group) as the downlink, a request is made to the uplink to get the area for your downlink. During this time, if configured, an echo area and/or a file area are created to accomodate this new areaname so that you are now ready to route files through to this downlink node. This feature has a second phase to it. Since you are getting these lists, why not put them to good use? Base Runner will go through your echo areas and update their descriptions with the new .NA or .NO files descriptions. Only .NA and .NO files are supported at this time. This is especially handy if you are a large hub and have many areas to manage. - Area Manager ------------ The file manager checks for any netmail messages addressed to it and processes them accordingly. This function is used for remote maintenance of the file echo areas any system may receive from you. This offers your downlinks(if you are a hub) an easy way of adding or deleting (as well as many other various operations available) echo areas automatically by remote netmail. This makes your file management system virtually maintenance free! - Automatically Maintains Outbound Que ------------------------------------ Base Runner looks at the Outbound Que(if PCB, or netmail directory) and checks for sent files and removes them from the outbound directory. This only applies to files move to the outbound area for downlinking, not those that were originals. They were attached from their home filebase so they are simply "unfrozen"(via the utility programs NOKILL maintenance operations) so that now regular filebase operations take effect. - File Echo Importation --------------------- The inbound directory is checked for new .TIC files and possible attached files. If any, they are imported to the system as you have defined. During this time the files may be imported to your filebases. If this occurs(if the area is not passthru), certain operations are performed on the file. For example, if the file is to be converted to an alternate archive type, it will first be extracted into your work directory(preserving all the original archives path information and any imbedded archives) after which it may undergo such tests as CRC,3 level duplicate detection,Add files, delete files, change/add comments, 2 way file id etc. File movement defaults are set up as well as other system info and the file is imported into your filebase for that echo. Full downlinking is supported with unlimited downlinking. - Deletions --------- Each Base Runner filebase is loaded up and compared to what's on disk. Any files that exist in the filebase but don't exist on disk are removed from the filebase. This ensures the filebase is kept up to date on missing files. - Age Deletions ------------- As above, but the file is checked for age against the specified number of days set in the configuration for this area. If this area is set to zero, then no age deletions take place for this area. Each area is checked in your database. - Adoptions --------- Again the filebases are compared against their associated directories but this time if a file exists on disk that doesn't exist in the filebase (an orphan) , it is adopted as a orphan file and processed just as an imported echo file is. That is to say that it falls under all the same testing as does the echo files imported such as Virus Scanning,CRC test, Add Files, Delete Files, Comments, 3-Way Duplicate scanning, 2-Way File id insertion etc. Finally, it is imported into the filebase and a new DIR file(or Files.bbs) is regenerated for the area. - File Movement ------------- Files are automatically moved between areas based on the area links you define in configuration. More on this in the next section. - Duplicate Checking ------------------ Filebases are checked for lines that duplicate themselves in the filebase. Dupe checking of the file is performed at any point a file can enter the Base Runner system. - User Upload Processing ---------------------- If a filename is found in a DIR file(or Files.bbs) and exists on the hard drive directory specified for that area, it is considered a user upload and processed into the system. Because we assume most systems already have a valid upload scanner(SpotChek by CompuData Systems is a popular one) and that the file has already undergone rigorous testing, we only do a minimum amount of testing on these files including CRC, duplicates, validation, archive stamp checking etc. These files are then imported into your filebase but a new DIR file is not generated as it is already in the DIR file(or Files.bbs). - Filebase Sort ------------- Filebases are sorted according to the sort order specified in file area configuration. - User Requests are Processed --------------------------- These are the requests users from other systems(who are involved in a request system with you) that must be filled. Of course the usual security checks are made to make sure this node is indeed authorized to take these files and that their limits have not yet been reached, but otherwise, a return attach file is sent to the requesting system. If the file is not found or fails for some reason, both you and the requesting sysop are notified of the problem so that you may sort it out later. New List updates and complete list generation are also handled during this operation as well as incomming files that your users may have requested from other systems. - DIR File Generation ( or FILES.BBS ) ------------------------------------ For those filebases that have changed,Base Runner regenerates the associated PCBoard DIR file. For this reason, changes made to the original listing file such as with PCBFiler may not apply. Functions performed with such utilities are done to the Base Runner filebases directly with the included utility, Bredit. It does everything the above programs do and lots more; a nice piece of work. - TrashCan File ------------- A textfile containing one filename per line of a node address which is considered to be "trash" or unacceptable. If this option is set to "on", all files from that node will sit in the inbound and not be processed. Also, this node address will not be added into the nodes database. This will be logged so you can monitor or add the node manually if you wish at a later date. Base Runner was designed in a very modular way, so these above functions plus many more can be enabled or configured through main configuration. Each file area on your system can be handled differently, as well as the files that enter into them. The thing you have to remember is that once you define one of your file areas under Base Runner it belongs to Base Runner. Manipulation of the resultant DIR file directly is possible but may not be desirable. Deletion checking and Adoptions will keep the filebase updated but what's in the DIR file is a perishable reflection of Base Runner's filebases. You don't have to surrender your entire system, you can include only those areas you wish Base Runner to look after. We put a lot of flexibility into the program so you're not tied to doing a lot of things you don't want. If one day you decide not to run it anymore, just stop using it. Your DIR files will continue on without Base Runner present. - Bad Files Area -------------- At various times during Base Runners execution, there may be times when certain files fail the operations performed on them for whatever reason. This is the time that Base Runner(if set up for it) may move these files to an area that is hard coded called "BAD_FILES". This area is automatically created by the configuration program if no files area database exists and uses certain defaults but you may change them if you like. The directory and specific DIR file(or Files.bbs) are also updated by this areas regular functions. This area is exempt from all file movement operations by default. It is also exempt from all deltions or any other scanning usually performed on the regular areas files. The reason for this is that we must assume that the file is either corrupt or not a file we can work with or it would not be here at all, so we must not touch it until you or one of your co sysops does something with it. This area is set up and its parameters established at start up and if it is not valid, Base Runner will bark up and refuse to run, logging the error as well as showing you on your screen. - Automatically Maintains your History File ----------------------------------------- There is a small file that records all files coming in and out of your system. This "History" file has alot of information about exactly what the file did when it went through. With this information, extensive bulletins can be generated(please read BRUTIL) to report statistical records of your systems file activity. The file simply keeps growing if it is not maintained, so if the number of "historydays" in your configuration is a value other than zero(zero denotes unlimited size) the file is scanned back to the number of days so that it stays "manageable" on your hard drive. 1.1.5 Other Considerations -------------------- The design of Base Runner took into consideration that you might not want to just hand over your entire file system to a maniac utility. I have a couple of areas on my BBS that are not touched by Base Runner. I use the usual PCBoard ways of managing those areas. When you define a file area under Base Runner, any maintenance outside of Base Runner is not encouraged.What I mean is, if you have Base Runner looking after new uploads, and you go in with PCBFiler and kill, move, etc.,Base Runner doesn't know about it. But it's not a disaster. First, Base Runner does (optional)checks and deletes filebase entries for non-existent files (ones you killed) and adopts files that just appear (ones you copied in). Base Runner comes with Bredit, a FULL featured file base editor like PCBFiler but LOADED with features for manual updating of your file areas if needed. Movement should be automatic, but some things need changing like file ownership as described earlier. If you don't want certain areas managed by Base Runner don't define them as a file area. No problem. It's left alone and you can use PCBFiler to look after those manually. If you want to run Base Runner strictly for the file echoes, you must define at least one file area. It can be one or more private to the BBS areas, also defined in your BBS setup. Since Base Runner reflects its system with a DIR file,files can be moved around the old fashioned way. The only weakness in all this is user uploads. We identify a user upload as a file that exists in both the DIR file and on disk,but does not exist in the Base Runner filebase.It is adopted and ownership is assigned to the area it was adopted in. We would like to have the ownership set automatic but there's nothing to tell us what area a file would belong to. This is the small manual maintenance required. You can define an upload area under Base Runner and set it to move files to your new upload area after 1 day. Use Bredit to assign the new file's ownership and run Base Runner.Automatic file movement will take over provided you have it set right. Of course these are only examples and are not meant to say this is how you must run it. Please consult the file STRATEGY.DOC for some info on different ways to set up your file/echo areas. Also something to consider is that this package is not crippled nor 'rated' in levels of advancement. We do not insist on "advanced" tic modes to have Base Runner include such things as LDesc in generated TIC files. As such, all the power available to you is right there in front of you. It has been asked if Base Runner will scan message bases for certain files requested and reply based on those requests. This is a feature of a BBS and Front Ends such as Front Door and is not within the scope of Base Runner, nor should it be. That not only serves to confuse but also adds unnecessary overhead. What length has been offered, however, is that there is a user request system that allows users to request files from other systems directly. Base Runner is not provided for 30 days and you are NOT required to register it to continue using it. There are very few features offered to registered users which make life easier but not unbearable. Base Runner may be used indefinately without a license in its present form. Evaluate it for as long as you like. If you think that some of the registered features suit you, then consider registering it, that is up to you. So you see we are not money grubbing hogs but a group of concerned sysops who would like to offer a better level of TIC/File processing that is within reach of all sysops. We know how hard it is to run a system without getting nailed for every piece of software you run online in order to maintain your system. With that we do ask one small favor of you. Please let us know how you like the software and if you wish to see something added or changed. If you see something that is not working properly, please contact us, don't be shy, we are more than glad to help and if indeed what you find is more than a configuration problem, we will endeavor to develop the product to your level of satisfaction. 1.1.6 File Area Links --------------- As mentioned,a file area in Base Runner is much the same as a file area on your BBS. The difference is, Base Runner file areas have names. Any old name that makes sense, as long as its unique. If you're used to file echoes, they employ the same thing but this has nothing to do with file echoes. Each file area you define allows you to configure two things about files entering that area: 1 - Initial area for uploads ---------------------------- Files uploaded to this area (assigned ownership) are to be placed in the specified area. So files uploaded to ZIP_UTILITY could be initially placed in NEW_UPLOADS. 2 - Move Files to Which Area ---------------------------- There are 3 main choices here. 1) Nowhere. Files are here, and move nowhere, even if they are owned by other areas. 2) Home. Files are moved to the areas that own them. 3) Specified area. You can specify that files in this area are moved to another area. Like, NEWUP30 configured to move files to NEWUP60 after 30 days. As you can see, based on this per area configuration, you can define chains of areas linked together that files follow. Like from UNTESTED to NEWUP30 to NEWUP60 to HOME and then deleted after 6 months if you want. The key to the accurate flow of new incoming files is how they are handled when they enter the Base Runner system.There are 4 ways: 1) File Echoes 2) User Upload 3) Local Upload 4) File Adoption File echoes are covered later, but ownership is looked after quite nicely by itself. User upload is based on the possibility that the user is an idiot, and needs a life badly. Meaning, its a wide open door as far as error is concerned. This is where the ability to change file ownerships in Bredit comes in handy. Local upload is YOUR fault. :^) When Base Runner adopts a file (one on disk but not in the filebase) ownership defaults to the area it was found in. 1.1.7 System Requirements and using SHARE.EXE --------------------------------------- There are only a couple of things you should be concerned about when considering the operation of Base Runner. You should have at least a 80386 processor as the code is optimized to omit code to support anything less than a 386 system. At least 512K of ram is required but is not totally used unless you have large filebases(greater than 65,000 files). This allows the speed necessary to optimally run systems that deal with such large amounts of data. If you run out of memory, the disk is used to swap memory in and out but is strongly recommended against as the thrashing on your drives may be intolerable and will result in a major speed loss. File sharing and record locking is used all throughout the code so it is absolutely necessary that you run a program called SHARE during your startup batch files.If you do not know anything about this program or its use,please consult your DOS documentation for more details.This is to accomodate PCB's configuration files that are read and written to often. Running SHARE.EXE is as simple as including the line SHARE.EXE in your autoexec.bat file but is good to know what it is and why you are running it. It is also absolutely necessary to have a valid FIDO address or this software is useless to you for any FIDO processing. Even the file requesting system, since the rest of it depends on it, also uses the FIDO standard as its interface. Base Runner will also, if configured, use PCB's netmail conference area instead of some other front end such as Front Door or D'Bridge, which use the MSG format. Either format is supported. The executable files are not very large, approximately 2.0 meg in size.You may not use a program such as PKLITE or LZEXE to make these programs smaller as they are overlaid for memory use. The reason for this is they are heavily overlaid. These code segments are calculated very carefully and if they are comressed,it messes up the whole virtual data tables in the executable. Unpredictable results will no doubt come your way in such a case,if the program will even run at all! The total size for an average system carrying 100 areas would apprximately total 2 to 2.5 megs of hard drive space. Not bad for what you are about see it doing. 1.2.0 Main Configuration ------------------ This section deals with the main Base Runner setup and file area management. It also includes information pertaining to file echoes. If you don't run any, the options for them are inconsequential. If you do, you should be familiar with the operation of a Fido front end mailer and its terminology. Main configuration is a program called BrConfig.EXE. It is a menu driven program with help at any menu or prompt with a press of F1. It takes no command line parameters, nor does the main program, Base Runner.EXE. The operation of the main program is solely dependent on the contents of the data files maintained by BrConfig.Therefore, BE SURE you have Base Runner configured right before you run it! If no configuration file is found in the directory you are run- ning Base Runner from, a default file will be created. Along with this, Base Runner will create a couple of directories for you so that you will be all ready to run right away. The config program will also create a new BAD_FILES file area, an area which is very important for all of Base Runners processes. If you have an existing system using another package, be sure to check that program to see if it supports your processor type. If it does(such as Allfix), you may choose to have it convert the configuration over to Base Runners format before you run the con- fig program. That way the files will be set up for you leaving you with a minimum amount of work! The main menu of BrConfig will appear and we'll start at the top and work down. Base Runner has MANY features and they will be covered as configuration is reached for them. First selection, System Info presents a sub menu with four options: 1.2.1 System Info - Paths/Files ------------------------- - Inbound Directory ----------------- This is the path where inbound file echo files are stored. It is typically your front end mailer's Inbound directory. - Outbound Directory ------------------ This is where Base Runner will store outbound file echo files and information. It is best that this directory be one that is unique to Base Runner and NOT the same as the inbound path or you will lose files. No other files can reside in this directory except the ones Base Runner is downlinking. Failing to move files out of this directory may result in them being automatically deleted as part of regular maintenance. - Netmail Directory ----------------- This is the path where netmail messages are stored. It is typically the same directory as your front end mailer's netmail directory. - Net Out ------- Alternate directory to place outbound netmail attaches. If this field is blank, it is ignored, otherwise this directory is used instead of the above directory. This is handy if you would like to temporarily output message attaches to an alternate directory. - Filebase Directory ------------------ This is the directory where Base Runner's file databases are to be stored. Usually \DBASE\FILEBASE, since many file areas can add up to a lot of files, keeping these separate maintains organization. This will only be a head directory. The actual directories that hold the bases will be under this one and will be called IDX,HDR and TXT. - Headers ------- Base Runner gives you the option of using DIR File headers and footers. They are, headers and footers at the top and bottom of the directory listings the user sees. Using PCBoard, Base Runner keeps these headers and footers in separate files. PCBFiler will trash the headers if they're included in the DIR file itself. This directory specifies where the individual header and footer files are stored when Base Runner generates them. Please do not confuse this with the path/filename of each header/footer in the file area configuration. They are to allow you to place the orig- nals whereever you like. This field is where all the new created headers/footers will be. You should not keep the originals in this directory. - Embedded Directory ------------------ This is a temporary directory to store embedded archives, ones in which archives exist inside other archives. This directory will be used to store these files that extracted from these embedded archives. The reason the regular work directory is not used is so we do not tamper with the original archives directories. This aids in the archive conversions where all original paths and sub dirs are preserved. - Log File -------- This is the path and filename of the log file that Base Runner generates during its operation. Although you can use an existing log file used by another program,its best to let Base Runner manage its own. Pressing F2 will invoke your external text editor(if configured below) so that you may see and edit this file. - File List --------- This option specifies where the master file list will be placed. See the option under "Global Options" for further information. This list should not have an extension as one will be added automatically(ZIP). - Hatch To? --------- The echo area tag the master list will be hatched out to. You may disable this feature by simply leaving this field blank. If not blank, the echo area is searched for in your echo database and if found, any nodes attached to that echo will recieve a copy of the master list along with the necessary tic file so that they may import the file just as any other file(and possibly downlink it themselves). - FTrashCan List -------------- Path and Name of a text file used as a File Trash Can. This is a plain vanilla text file with one filename per line, wildcards accepted, of the list of files you will NOT accept on your system. Please note that this is ignored by the echo modules because it is assumed that your downlinks may still want the file, so it is echoed out as usual. Pressing F2 will invoke the external text editor(if configured) so that you may edit it directly from the config program. - NTrashCan List -------------- This is a text list of nodes you wish NOT added during auto node add. One node per line, you may use wildcards ... 1:229/428 These are all valid entries. 1:229/* 1:* if no zone is specified, your main aka zone is used by default. You may press F2 to edit this file directly if you have configured the external text editor(please see below). - Uplink Lists Directory ---------------------- A path to a directory where Base Runner will maintain its uplink lists in. This is the path where new updates of your uplinks lists will be kept. Up to 15 lists per node may be specified. All of the lists will be in this directory. If you are not hubbing, this will not be of any consequence to you. - Work Directory -------------- Base Runner needs a unique directory for storing temporary files. It can be anything like C:\BASERUN but nothing else should use it as Base Runner frequently deletes this entire directory and everything below it(because the archivers sometimes create sub- directories). Please make sure there are no sub directories to this one. - External Editor --------------- This is the name of the program you wish to use as an editor for the files descriptions. There is one built into BREDIT, but this may give you more of what you want. We know how people can get attached to "their" text editors so we offered this feature. Of course you can still use the built in one by pressing enter, but pressing F2 in the edit window will pop up your editor instead. We have tried to test this with as many editors as we could and found a problem with some(like DOS' edit for example) of the editors. The reasons for this are as varied as the editors themselves. In an effort to be as compliant as possbile, we have attempted to have BREDIT run with the widest possible width of editors on the market. If it simply resets the font and then sets it back, the shell to the editor failed and control was returned to BREDIT. In this case you may either use the built in one or find another editor. We have had good luck with the program called QEDIT here. Qedit is a program which requires certain things in order for you to run it, so please consult any documentation in regards to that or any other product. - Magic File List --------------- Path and Name of your Magic File list. This is a list with a particular format in the form <MAGICNAME> -whitespace- <FILE>. MagicName is the actual magic name that is scanned for. File is the file(s) that will be used (wildcards permitted) for the file translation so that all files matching this filespec will be sent out as a file request. This is usually also used by most front end mailers but is primarily designed for use with BRFreq's file requesting system. - CD Drives --------- These are the drive letters of your configured CDROM drives. Only the character letter of the drive is necessary. Base Runner checks all drives for available disk space and cross references these against your minimum setting to see if files may be moved or copied there but also serves as a system for recording your CDROM drives as well. Example... "EKI" .. would mean that drives E, K and I are all CDROM drives and that Base Runner should not try to perform any copies or moves to those areas. - Ann. Dir(Announce Directory) ---------------------------- This is an alternate packet directory for announcements. Normally, when an announcement is created, it is appended to a packet that originates from the node who sent you the file for which that announcement is being made. There are times, however, when you will want to place these packets into another directory (secure directory for example). If nothing is entered into this field, then inbound directory is assumed. 1.2.2 Systeminfo - Global/System Information -------------------------------------- This is general information, mostly for use on reports and so on. Their use will be shown in later spots, but the info required is basic. DIR file headers and footers can use this info, as well as notify reports for file echo operation. - BBS Name - Name of your BBS; "Steve's BBS" - Sysop Name - Your Name. A toughie. - Phone - Your phone number. - Location - City, etc... eg. Oshawa ON Canada - Area Mgr?(or File Mgr)? ----------------------- Should Base Runner perform Area Manager operations? Even if this is set to "Y"es you can disable it via the command line switch "NOMGR". Read Section on Area Manager for more info on Area Manager activities. - Move Duplicates to BAD? ----------------------- Base Runner treats the file area named "BAD_FILES" as a special area. If it exists, certain functions of Base Runner such as duplicate checking move duplicate files to the file area "BAD_FILES". If the file area doesn't exist, duplicates are deleted. "Y" here indicates you want duplicate files move to the BAD area. Otherwise, duplicates are deleted. - Duplicate Limit --------------- Base Runner maintains a file internally called BRDUPE.DAT. It holds the CRC values of the most recent files entering the system. If a new file via user upload, file echo, adoption etc. enters the system and has a CRC value that matches one in the duplicate base, it is considered a duplicate and dealt with as per the above option. This option specifies how many files to maintain in the duplicate base. BrUtil has a function that packs the dupe base to say 10,000 files if that's what you specify. That amount would be average since the larger this number, the larger the duplicate base. - User Uploads? ------------- This is the system wide toggle for disabling the User Upload operations(registered). - Add Node? --------- This tells us whether you want Base Runner to automatically add nodes to your database as they are encountered. Beware of the security implications of this type of move. To help you with security, Base Runner maintains a list of "trashcan" nodes that it will not relate to in any way. - Auto Uplink? ------------ Should Base Runner automatically search for uplinks and their lists to connect a new echo area request? This applies to Area Manager operations where a node has requested an echoarea which is not currently in your database. You can have Base Runner automatically generate a request to your uplink to connect you(as well as the requesting node) and your downlink to the new area. This area is created and added to your database so you are then ready for new files moving in and out of that area. - File Sys. --------- A two item menu with either PCB or FILES.BBS choices on it. Both formats are fully supported and maintained. PCB DIR files are the ones most commonly referred to in this manual and are the standard file used for PCB's file system. Files.BBS, on the other hand, is a much more widely used format by a number of popular BBS's. These have a very similar format but are certainly not the same in the BBS's operations, so make sure your system supports either of these types. - History Days ------------ Number of days that will be kept and maintained in the history file, BASERUN.HIS. This number will be the number of days that Base Runner will go back in its history reports and is also the way Base Runner calculates how much of the file to trim if it needs it. This information is used for posting to messages or to a text file or to a bulletin. - HTML Bull --------- The reports generated by Base Runner come in two flavors. One is the obvious flat text that everyone is so used to and is the fastest in execution(by a millisecond or so). HTML is a style of report which uses special control strings to tell the HTML server how to format the text, font sizes,lists etc...This aids in almost giving your reports a World Wide Web appearance and can actually be used as part of Web Pages. - Video Mode ---------- Here you have 3 choices for video modes. With this set up you no longer need to enter it on the command line. Please note though that the command line will override your current configuration setup. The 3 choices you have are... 1 - Quiet : This will run the main Base Runner program in what we call stdout mode or flat grey mono mode with no boxes or fancy fonts and no 16 color ega palette either. This is handy for unattended mode or if your current setup is not working in the higher resolution well. We endeavor to be as compatible with as many systems as possible, but it quite often happens that our current VGA routines may not be compatible with your particular video card. 2 - EGA : This will run in 16 color standard EGA mode. You will get the boxes in color, but not the fancy fonts. They are only available in VGA mode. 3 - VGA : This is the fanciest output there is, with 256 color palette and specialized fonts. Not all systems can run this mode successfully in which case you should shift down to one of the lower modes. - Time Zone --------- The TIC standard requires a time zone. F2 will present a list of time zones for you to choose from if you're not sure. It's a 3 character value that would contain something like EST, PST, etc. - Net Retry --------- Base Runner supports networks and with networks come possible clashes with file sharing.If Base Runner tries to access a file on a network currently being modified by something else like PCBoard,this specifies the number of times Base Runner will retry the file before giving up. A value of 0 says forever. - Retry Delay ----------- This option specifies the delay between the above number of retries on locked network files. 0 means no delay. - Text List? ---------- Base Runner supports a master file list function. So many BBS's distribute a master file list as one huge text file. What's anybody going to do with a 4 meg text file? So Base Runner will generate one of 2 types of a master file list. Specifying "Y" here will have a separate text file for each defined file area zipped up into the file you specified in Paths/Filenames. If you say "N", Base Runner will generate its own format of file listing, and attach the viewer (BRVIEW.EXE) along with it. This way the user has a manageable utility (a scaled down Bredit) to view, print or export the file list. The list is generated by a function under BrUtil. - PCB Net? -------- There are currently three types of netmail handling for Base Runner. The first most commonly used one is the *.MSG format used by many popular front ends and BBS's. The second and third, which are broken down only by whether or not your PCB version is 15.21 or later. 15.21 has a unique outbound QUE file that must be treated differently. This QUE file as well as some other subtle changes are the only differences in these choices, otherwise, you will still need to use the *.MSG handling that PCB offers in order to properly use Base Runner. Please consult your PCB documentation for more details on how to properly implement the FIDO capabilities of your PCB system. The only time you won't need one of the PCB netmail toggles is when you do not run PCB at all. - Auto Hatch? ----------- This tells Base Runner if it should automatically hatch out new files found during file adoptions(or RAW DOS orphans). The default echo area specified for the particular area the file was found in is the echoarea name used to hatch the file out. Also, the downlinks for the echoarea is used for hatching. This can also be disabled via the command line. Please Read the section on "Using Base Runner" for more information. - Scr Blanker ----------- BREdit has a built in screen blanker which will dim your screen after this specified number of minutes has elapsed with no activity on either the keyboard or the mouse. After the screen has blanked out, you may press any key or press the left mouse button to light it back up again. - Minimum Drive Space? -------------------- This is the minimum drive space required before files can be copied or moved to destination drives. This value should be entered in kilobytes. (Bytes divided by 1024). If no setting is provided, the default of 5000 (5 megs) is provided for you. - Log Format ---------- Base Runner supports many logging styles. This is constantly being added to but at the time of this printing, the following types are supported... - Front Door (or Intermail) - QFront - Remote Access - PcBoard - Base Runner (something different) Selecting on the menu the type you wish to use will alter that type to the style that is seen in that type of log format. 1.2.3 System Info - Network Addresses ------------------------------- These are network addresses you may have within a Fido type network.They can be up to a four dimensional address,but must include at least 2 dimensions. I'll explain. A Fido address is comprised of up to four possible numbers: Zone:Net/Node.Point ...or... 1:229/428.2 The first number is the Zone, and usually refers to a major geographic area such as North America or Europe. It can also refer to another type of network other than Fido such as SearchNet (Zone 114) or DharmaNet (Zone 96). The second number is the network number within a particular Zone. The third number is the node number within a particular net, and the fourth is a point number. The Zone number is optional if you're only dealing with one network. The point number is optional unless you're a point under an existing node. In any case, a net/node number MUST be present. ie. 1:229/428 229/401 401 <- Invalid! Remember these are YOUR addresses. Only one is required but you may enter as many as you have up to 10. The first address in the list is your main address. You will find reference to what you enter here when (and if) you configure file echo areas. 1.2.4 System Info - Origin Lines -------------------------- There are up to 50 origin lines you may have added to messages that are generated by Base Runner. You may enter any text you like. This text may include PCB's @-codes(as long as others will tolerate it!) or whatever text you wish to insert. Afterwards, when you are in echo areas, you may select from a list of these origin lines, one for each area, and have Base Runner use that particular one for that particular echo area. Not much more need to say anything on this one. 1.2.5 System Info - Virus Scanners ---------------------------- Here you may enter up to 10 virus scanners to run on each imported file. This may seem like overkill but it is for those who are weak at heart and/or a little paranoid. Just leave any program field blank to disable that particular virus scanner. Leaving one empty will not disable one after it, they are all checked for validity. Two fields apply here, the program name(include the .EXE for speed) and the command line. These should be self explanatory. As with most programs, a zero errorlevel is assumed to be a successful return. 1.2.6 System Info - Compression Formats --------------------------------- Base Runner supports an unlimited number of archiver types. The first seven are already filled in by you and should never need to be changed for any reason. They are also there to provide you with a guide for future entries. It must be now stated that there are NO other TIC/File systems that deal with this properly at the time of publication of this document. The reason for this is that no one program allows for all command lines to be entered, does not allow for the possibility of a non recursive archiver(such as older PKARC or PKPAK) and while some archivers may indeed recurse(pull in sub directories) , they do not necessarily put those sub directory paths into the newly created archive. Base Runner covers ALL the bases(pun fully intended) here. Base Runner does not rely on your archive extension to provide proof positive that this indeed is the archive type we are looking for. Instead we use what we refer to as an archive stamp, a series of identifying bytes at a given offset of the file. For example, some are easy... RAR uses the word RAR! at offset 0 but some others do not provide such an easy way to identify themselves. Base Runner provides up to 10 byte values as an array of bytes in order to identify an archive type. Enough of the technical issues, lets get on with it. In order to do that, lets first discuss one archiver itself. This means that we are discussing what you would see if you were to press enter(for editing) on any one of the archivers you presently see in the window. Each item of this window is explained here... Ext. ---- Only used as a way for us to know the difference between types, this is the 3 character extension of the archive, for example ZIP, ZOO, ARJ etc. This has no meaning nor is used in any other way except to identify which archiver is which. Stamp Offset ------------ The offset(how many bytes into the file from the beginning) of the beginning of the archive stamp(see below). Recursable ---------- If this archiver is capable of taking sub directories and storing them into the archive along with their respective files. Most archivers do nowadays, but some older ones don't. This is especially important in the case where you are performing archive conversion. If you insist on converting to a type which is not recursable, understand that you are losing the integrity of the archive by placing all the files into one main directory. More about conversion later. Extract1 -------- Recursable command line, if applicable, or empty if this archiver is non recursable. This should include the switch on the command line to include recursion, usually optional. There are two macros available here, %F for filename and %D for the directory. The %F will be replaced with the current filename being worked on and the %D will be substituted for your work directory. Extract2 -------- Opposite of above, this is used to NOT extract paths but to place all files in one directory. This is in case we are converting to a non recursable archiver type, we want to make sure to place all files into the main directory so that the other archive type(the one we are converting to) will be able to at least see all the files. This is not to even mention that we feel that to convert to a non recursable type will fail to maintain archive integrity. As above, the two macros, %F and %D can be used here. See below for a complete list of available macros. AddFile ------- Command line for adding files to an archive. One file or many files may be inserted depending on the % parameter in the file area editing so no "%" is required here, only the macros supported for this section of editing. These macros are %F and %A. DelFile ------- As above except this one deals with deleting file(s) from the archive. These may include such files as known BBS ads. Some processors allow the manipulation of distributed archives. We feel this is a violation of how the archive was intended to be distributed and will not support that aspect of operation, however, we do allow you to manipulate the files coming onto your system. Above only deals with echoed files. Available macros here are %F for filename and %S for stripfile(or delfile). Comment ------- Command line for inserting comments into archive headers. Available macros are %F for filename and %C for comment file or comment line. Convert ------- Here we must point out how the archive conversion works. As you may already know, all files get extracted into your work directory, possibly recreating sub directories where needed. As well, all embedded archives are extracted into the embedded work directory(just to keep it all organized for possible conversion). With this, you must use a recursive call to include all sub directories on this command line. If you have this set to non recursable in the toggles above, then the original archive type should have only extracted files using extract2 command line, so this archive type will still see all the files, it won't keep the original directory structure. Starting to see why we need two extract command lines? One to recurse subs and the other not to. Stamp ----- As explained above, this is the archive identifying stamp that is found in the file at a certain offset(see above). Placing a zero in the last position tells us to stop comparing bytes, so it can be considered an End of Line marker or delimiter. You may place up to 10 bytes into this field. 3 digits ranging from 0-255 are allowed here, but no higher as it is impossible to have a byte with a value higher than 255 in the file. Please note that this is not hex as with other processors. This is a digit format, much easier and faster in execution. So, for example, using RAR would have the characters Rar!, which would translate into 82(R) , 97(a), 114(r), 33(!). This may seem confusing but it is very efficient. Besides, almost all archivers provide these values for you in their documentation. If you are confused about a stamp, please send it to us, we will set it up as a default and give you back the modified dat file. Summary of supported Archiver macros ------------------------------------ %A - AddFile(s). %C - Comment file(s) %D - Work Directory. %F - Archive filename. %S - Del file(s) (or Stripfile(s)) 1.2.7 File Folders ------------ File Folders are a way of giving some common point of reference between file areas with similar qualities. For example, you might have public areas and private areas and want some way to differentiate between the two. In file area configuration, where you specify which file areas Base Runner will maintain, each area is assigned to a folder you specify here. If you define two folders, Public and Private, each area you define in file area configuration will belong to one of these two folders, whichever you choose. Their most efficient use is in echo area configuration, where folders have a strong bearing on security. Any other BBS Base Runner might feed will have access to selected file folders. There is more detail on this aspect later on. For the most basic configuration, one folder is required and no more. You can ignore the feature if you have no use for it. You may find the need for them as you go through file area configuration. One thing to remember, file folders are ECHO oriented and used only by that end of the system. We found it necessary to implement a security type of system for the requesting end of things. For this reason, please don't run off configuring these folders for file requesting. For those you will assign a security level to each node. More on security levels later. 1.2.8 BrConfig Databases ------------------ Before going any further, something should be said about how BrConfig handles its own information. For Node Info, File Areas and Echo Areas, BrConfig uses an indexed database to store each record. Manipulating this database has been made fairly easy. When you first enter one of these sections you get a horizontal list of any existing records. You can cursor/page up/down to move through the records. All operating commands are done using ALT keys. The following is a list of available commands, but note that there may be extra options specific to what the database covers (file or echo areas etc.). ALT-A - Add a new record ALT-D - Delete a record ALT-F - Find/Searching Functions. ALT-G - Global Menus(except Nodes). ALT-H - Help. F1 will do the same job. ALT-P - Pack deleted records ALT-X - Immediately exits configuration program, saves files. Note that deleting a record only marks it for deletion. ALT-D will toggle deletion status on and off. ALT-P actually removes the records from the database. - Common Cursor Commands that are Used by all Databases. UPARROW - Moves current selection up one item. DOWNARROW - Moves current selection down one item. PAGE DOWN - Moves current selection down 15 items or end of file. PAGE UP - Moves current selection up 15 items or to top of file. CTL PAGE UP - Same as two pages or 30 items up. CTL PAGE DOWN - Same as two pages or 30 items down. HOME - Two way function. If not currently at top of screen, moves current selection to top of screen, otherwise to top of file. END - Two way function. If not currently at bottom of screen, move current selection to bottom of screen, otherwise to bottom of file. ESCAPE - Always takes you out of (backs up) the current database or out of whatever operation within that datbase you were doing. This is not limited to the databases but is consistently the way to back out of ANY operation at any time. 1.2.9 Node Information ---------------- Node information is another database which keeps track of all nodes you communicate with. If you are sending or receiving files to/from other systems they MUST be declared here or Base Runner will not recognize them.If you don't plan to run file echoes or file requesting this section can be ignored. The information is minimal but required. However, before we continue I should explain a couple of terms used in this section and how they apply. Uplink Lists/File Lists ----------------------- An uplink is the system you get your files from. You could get files from more than one place, but we'll focus on a basic Fido setup to make things easier. If you are hooked into file echoes via the Fido backbone, typically you'll get your files from a central hub or host. This host is considered your uplink. Any systems you pass these files on to are your downlinks. To your downlinks, you are their uplink. An uplink list is a text file containing a list of file echo areas available from your uplink. Base Runner requires a text file, one file echo area per line. Each line should have a valid file echo area name such as PDNCEE followed by a space and optional description for the area. You can have up to 15 uplink lists for each node you connect with. Auto Area Creation ------------------ Normally if you request new file echo from your uplink you have to manually create a file echo definition (explained shortly), a directory to store the files and so on. Base Runner gives you the option to automatically create a file echo area and its directory. More details on this to follow. Auto Unlink ----------- Say one of your downlink requests an area called PDNCEE. You set the area up and get the feed going from your uplink. Then your downlink doesn't want it and disconnects it. You're left with an area you don't want. Auto unlink will monitor this area to see if there are any downlinks declared for it. If there are none, it will generate an area manager request to your uplink disconnecting the area for you. This is mentioned here only it is node related, but it the work is done via BRUTIL.Please see section under BRUTIL for more details on Auto Unlinking. Area Request Forwarding ----------------------- Any of your downlinks can request echo areas available on your system. If you don't have an area they might request, normally they're sent a netmail message stating the area is unknown. However, this could be an area available from your uplink. If you enable request forwarding and a downlink requests an echo area not in your configuration, Base Runner will search the uplink list you've declared for this node looking for that area. If it's found, an area manager request is generated for your uplink requesting the area be connected. With these few concepts in mind it should be easier to understand the options below which refer to each node you communicate with. - Address ------- This is the Fido address of a given node you communicate with. It is a 4D address as specified earlier. If you enter a partial address here such as "400", Base Runner will rebuild your entry based on your primary node address. For example, if you entered "400" here, when you move to the next field it will change automatically to 1:229/400. - Route To -------- If you would like to temporarily reroute files to an alternate node on this nodes account, you may do this by specifying a node address in this field. The Address field is ignored while there is a valid entry here. - Sysop ----- This is the name of the sysop of your system. - Area Manager Password --------------------- This is the password used by the specified system to access the File Manager. More on the File Manager later. - Folders ------- This is a pick list of the folders you defined earlier. You hit the spacebar for every File Folder that this node has access to. For example, say you defined two groups, one Pay Echoes and one Free Echoes. Under File Echo Configuration you specify which folder each file echo belongs to. Then here, you specify which of those folders this node has access to. So if this system is behind on payment of pay areas, you can just untag the Pay Echoes folder here and he can no longer access these areas using the File Manager. - Attach Flag ----------- This is the attribute of netmail messages sent to this system. There are six options here: None - Normal routing looks after sending. Crash - Messages are sent NOW. Hold - Messages are held for pickup. Not sent. Direct - Messages are set up as direct with no routing. Crash Direct - A combination of Crash and Direct. Hold Direct - A combination of Hold and Direct. - Auto Create? ------------ This option enables the auto area creation feature as explained above. This needs some explaining. Since Base Runner has a two tiered system of echo areas and file areas, there has to be some provisions made to accomodate the differing scenarios desired. The first menu item here is Off, which is simply to turn off auto add altogether. Please remember that you are then required to add the area yourself or disconnect it from your uplink. The second option is Clone Farea, which means that a file area is created for each echo area created with its own unique directory , filebase and descfile. This will ensure that each echo area is attached to only one file area,the opposite being a very powerful feature of Base Runner which brings us to the third item. Use Initial tells Base Runner that you wish a new echo area to be created but to have this area point to an initial file area as specified in the initial field of the echo clone record. In this case the initial field becomes the name of the file area that all files entering this echo will go to. You might want to play with this to achieve the desired result as there is much flexibility. The last item therefore allows all new echo areas from one node to point to only one file area, allowing you to later go and reconfigure to a new file area or to push all files entering the system from that node to see only one file area. This also allows categorization of nodes so that one area may be devoted to one node. - Clone Farea? ------------ If auto creation is enabled, any time an area is auto created it needs a guide for the various options in your file area configuration. If you like you can create a generic file area used strictly for cloning. So if the area PDNCEE is automatically created, the new file area will take on the options the file area you declare here currently has with two exceptions. The first is of course the area name. The file area name will be the same as the file echo area name. The other is the path to where the files are stored. Say the area you are using for cloning is C:\FILES\IBM. Base Runner will recurse this path one directory and replace it with the first 8 characters of the echo name. So if the area PDNCEE was being created, the path in the new cloned area would be C:\FILES\PDNCEE. Note that if you haven't configured file areas or echo areas yet there will be no areas to choose from. Do that first and then set up area cloning. - Clone Fecho? ------------ This is similar to the above, but refers to the file echo record in Echo Area configuration. As with the above example, the echo area record you specify here will be used to create a new record. The initial area to place files in this echo will be the same as the area being cloned. The area that owns files coming through this echo will be PDNCEE (if that is the area being created). All other options follow the area being cloned. - Announcement ------------ Announce to which area is the main point of this field. Enter the echomail conference you would like this echo area to announce to. A packet is generated(or appended to if one from this node already exists) and this message is added as an announcement. If that area is set up as an echo area and your processor can scan outgoing mail, you will then notice the message going out to other nodes as well as going into your message bases. Remember that this is only for user requests and not the announcements used for echos. - Request System? --------------- This is for PCB sysops only. You may connect to this system for offering your users access to their files area. Of course only the areas they are configured for and the ones you have enough security for are open to you. Answering "Y" to this question will automatically signal BRFREQ to include this systems name as one of the available systems from which your users can request from. Please remember that you must have a directory and their files areas data files in order to operate properly in the door or your users may get confused, so answering "Y" to this requires that you completely set up this node for user file requesting. - System Name ----------- The name as it will appear to the users who are using BRFREQ. When they go to log onto (or enter) another BBS, they use the "S" command. This name is what is used as the system name for this system. - Request Directory ----------------- The directory(no backslash) of this nodes files areas databases and control file(AREAS.CTL). This directory is automatically maintained by Base Runner and used to store all of this nodes areas and requesting info in. - Security Level -------------- Security level for this node. This level is compared to the level specified for each file area. If this node has enough security, they have access to that area, otherwise, it is invisible to them or their users. Requests to this area are ignored as well. - Request Message Base -------------------- This is the echo area name of the message area you wish the announcements to go to for incomming files from this node. You will have to(if you want to keep it local) set up a dummy echo area in your echo processor to import these messages with no downlinks so that it remains local or you may announce each users incomming requests to any echo area. Packets are generated for these messages similar to regular Announcements. - Request Message Text -------------------- As with Announcements, this is the templated text file that is used for the generated messages. It is replaced using any macros found in the original and the new packet(or an existing one) is appended with the new message. Your regular mail processor can then process the incomming mail as it normally would. - Day Bytes(K) ------------ This is the number of kilobytes this node has taken today. If the bytes cap is set to anything other than zero then that value is compared to this one to see if this one has exceeded the set limit for the day, otherwise it is incremented here and also incremented in the totals field as well. You can reset this without affecting the totals field. This applies to user requesting only and does not affect the regular nodes echo statistics. - Day Files --------- As above except that this is for file instead of bytes. The same rules apply to the files cap if it is a value other than zero and resetting this does not affect the total files field. This setting pertains to user requesting only, not echo traffic. - Total Bytes(K) -------------- The total kilobytes this node has taken to date or since the last time you reset this value. As above, this field applies to the user requesting operations and not the regular echo traffic. - Total Files ----------- The total number of user requested files this node has taken to date. This may be reset at any time. - Bytes Cap(K) ------------ Number of kilobytes this node can take each day for user requests. If this number is set at zero, it is assumed as an unlimited value and will not be checked. - Files Cap --------- As above, but for files instead of bytes. If this value is set at zero, unlimited is assumed. - List Delay ---------- The number of minimum days before and update will be sent to this node. This is handy if you are long distance or do not want too many copies flying back and forth. These are the lists that you maintain for this nodes file areas for your user requesting system. If this value is zero, lists will be updated as they are needed(default). - Kilobytes In (back to regular input screen) ------------------------------------------- This is the total kilobytes that this node has sent you. It reflects the total amount since the last time it was reset. Please note that this field is for echo activity and not user requesting activity. - Files In -------- As above except for files instead of kilobytes, it reflects the total this node has sent us. - Kilobytes Out ------------- The total kilobytes that we have sent this node to date or since the last time it was reset. - Files Out --------- The number of files we have sent this node to date or since the last time it was reset. - KB Cap ------ Kilobyte cap for this node. When this total is reached, all echo activity for this node is stopped and any files going out to this node will be stopped at that point. - File Cap -------- As above, except that the cap is for the total files this node can take instead of kilobytes. - Area Manager Name ----------------- Your uplink may be running a file echo processor other than Base Runner and Base Runner has no way of knowing who to address requests to. eg. FILEMGR, TICK, ALLFIX, etc. This field specifies the name your uplink will recognize as a file echo area manager request. - Area Manager Netmail Status --------------------------- This is the attribute of Area Manager netmail messages sent to this system. There are six options: None - Normal routing looks after sending. Crash - Messages are sent NOW. Hold - Messages are held for pickup. Not sent. Direct - Messages are set up as direct with no routing. Crash Direct - A combination of Crash and Direct. Hold Direct - A combination of Hold and Direct. - Days to Keep? ------------- Most TIC processors force you to register for this feature but it is included with the Base Runner package. This setting tells Base Runner how many days you wish to keep attached TICs and files around before deleting them. This may be a value between 0 and 65535. A setting of 0 denotes unlimited days. - Notify? ------- This tells Base Runner whether or not you wish to send this node notify lists when invoking BRUtil to generate the necessary netmail attaches. Any node may get a list but it is only going to reflect the areas they are hooked up for as well as some other system related information such as Traffic statistics and passwords etc. BRUtil may be set up using the command line version in an event periodically to update your downlinks(for example) or any other nodes set up for notify with this notify list. - Advanced Tic? ------------- There are currently two tic format modes available in Fido today. You can use "Normal" or "Advanced" tic modes using Base Runner. If you select "Y" here, the advanced tic will be created or if you press "N", the normal tic type will be use. The more advanced tic type includes such fields as LDesc, To and a couple of others where the normal style does not. - Maximum Downlink Archive Size ----------------------------- You can limit(or the downlink can limit) the size of the out going archives to a particular node. This is the maximum size in kilobytes of the archives. If an archive is found to have reached the limit, a new archive is created and processing continues. This value may be any value between 0-65535Kb. - Compression Format ------------------ Further to the Ticmode selection, the "packing" stated refers to the compression of the tics and/or files into archives. Base Runner can support an unlimited number of archivers so with this , all these types are available to you to use as a default for this node. This will only be active if you are sending TICs or files to this node, meaning this node is a downlink from you. - TicMode ------- There are a few selections available to you on this menu.First, this is a menu where you can select the ticmode for this node. Ticmode in this instance refer to the way that this node receives their files. The following are available and are explained a bit further... File - Just sends a file, no tic nor compression used. Pak Tics - Pack TIC files but attach files regularily. Tic/File - TIC and file is attached normally. (default) Pak Files - Packs files without TIC files attached. PakBoth - Packs both TICS and files into one archive. So you see, there is a lot of power here. You can send files or pack files or pack tics and send files or pack files and tics etc... 1.2.10 BBS Areas(File Areas) --------------------- Think of the file areas on your BBS. You have a DIR File that holds the information about the files that reside in a directory on disk.A file area under Base Runner is the same thing except for one difference. It maintains its own file database with the same information as the DIR file plus a bit more. It is also indexed for faster processing. The actual DIR File is a reflection of the Base Runner filebase and is regenerated any time the filebase or the associated files change. Everybody has a new upload area. Each file area you define under Base Runner requires a unique one word name like NEW_UPLOADS. Note that although file echoes have a similar naming procedure, this is NOT the same thing. It denotes file ownership, as described earlier. This section of configuration allows you to define as many file areas as you wish.It uses an indexed database to hold the areas you define.So what do you define? Start with NEW_UPLOADS. Enter the areas under Base Runner just as you did with PCBoard. Something else to note is that a file area under Base Runner has a certain behavior.Files entering a given area are processed in some way and in this section are MANY options for how the files in each area are treated. NEW_UPLOADS may be configured to convert compressed files to ZIP and scan for viruses whereas the area GAMES-A_L may not have any processing done on its files at all. Base Runner is very flexible in all aspects of file maintenance and it will do just what you tell it so be careful. Each option will be covered in detail, and this one section will complete basic operation. - Area Name --------- This is a unique name given to a file area. It MUST be one word. You can use dashes and underscores within the name also. The only thing to remember here is that the name is unique. It can be the same name as a file echo, but you cannot have two file areas with the same name. Pick any name, it doesn't matter. Examples are NEW_UPLOADS, NEWUP90, IBM_GAMES_A-L, etc. - Description ----------- This is a short description of the area such as "New Uploads" or "IBM Games A-L". It will appear in DIR headers/footers and various reports. It can be anything you like. - File Directory -------------- This is the path to where the files for this file area are stored. BrConfig will strip a trailing backslash if you add one and verify that the directory exists. If not, you will be prompted to create it. - BBS File Base ------------- This is the path and name of the PCBoard DIR file that holds the information for the files in this area for the BBS.Base Runner will regenerate this file as it processes based on the information in the Base Runner filebase. Please note that for FILES.BBS type systems, the actual name of FILES.BBS need not be added to this name, rather just the path(excluding trailing backslash) to the FILES.BBS file. It is usually placed in the same directory as the files for that attached area. This allows for the lack of space in the editing field for FILES.BBS systems. With PCB systems, Base Runners editing field length matches that of PcBoards so it is not a problem, but with other systems, there are sometimes longer fields offered. - File Base --------- This is the actual filename of the Base Runner file database for this area.Base Runner filebases consist of 3 files. Say you enter NEWUP in this field. When Base Runner processes it will create: NEWUP.HDR - Holds information on all files in this area NEWUP.IDX - An index to the above NEWUP.TXT - Holds all the description text for that area You can call the actual filebase anything, but it must conform to DOS file naming conventions. - Folder ------ This assigns this area to a folder you have defined previously in configuration. Say you defined two folders, "Private" and "Public". If the current area is private, assign the appropriate folder to it. - Hatch To? --------- An area that new adoptions will hatch new files to. This is an echo area that is configured so that if adoptions for this area is on then this will be the echoarea that this file will end up being hatched to. This echo areas nodes including uplinks will receive both a netmail attach message and an attached TIC file. Each nodes message status bits(CRASH, HOLD, NONE) are set up in each of their messages so that your mailer can know how you want their mail to be handled. This is handy for putting cerain nodes on hold in case they are polling you instead of the other way around. - BBS Header - BBS Footer ---------- In your PCBoard DIR file, Base Runner can place a header at the top of the listing and a footer at the bottom. If you leave these fields blank headers and footers are ignored. If you place a path and filename here, Base Runner will use the specified files as the header and/or footer. Headers and footers are fully configurable. One example of each is included in the distribution package. See the later section on Custom Headers and Footers on how to create your own. - Add File(s) ----------- This allows extra files to be added to compressed files that enter this area. These can be BBS ads and so on. You can specify a single filename here, or if the filename is prefixed with a %, it is assumed you are specifying a text file with a list of files to add. For example: C:\DBASE\BBSAD.TXT - Adds this file to files entering this area. %C:\DBASE\BBSAD.LST - Adds files listed in this text file. The file can be any name, and must contain one filename per line, any number of lines. - Del File -------- This functions basically the same as the above option except the file(s) will be removed from compressed files. - Zip Comment ----------- Some compression formats such as Zip can have a header placed within the file that is displayed when the file is decompressed. You can either enter a single line of text here, or specify a file to use as the comment by prefixing it with a % like above. The difference between the above and this is that the above takes a file with a list of filenames and adds them to the compressed file. This option uses the entire content of the text file as a comment. That text can be up to 80 characters wide, but should remain under 25 lines long (a full screen). Note that special codes such as ANSI or PCBoard @ codes should not be used. ANSI codes are stripped by some compression programs. - Max Files --------- Specifying a number here, limits the number of files in this area to that number. So if you enter 1000 here, and during a process Base Runner moves files 1001 & 1002 into the area,the two oldest files are deleted. Specifying 0 here disables this function and lets the area take files as normal. - Delete Age ---------- Base Runner will delete files by age in a file area.If you specify 90 here, files older than 90 days are deleted. Specifying 0 here disables this function. Please do not confuse this feature with the "Deletions" switch below. With that function you are deleting any records that don't have an existing DOS file in its directory. - Traffic ------- - Convert? -------- Enabling this option will convert all recognized incoming compressed files to this area to any other recognized format. The destination format is specified below. - Virus Scan? ----------- This option will cause Base Runner to scan any files into this area for viruses using the program defined in System Info. Any files that fail are either deleted or moved to the BAD area, whichever you specified in System Info. - Dupe Check? ----------- Check this area for duplicates? If yes, duplicate files and filebase entries are either deleted or moved to the BAD area. - Deletions? ---------- One of Base Runner's features is the ability to compare the directory and the associated filebase, and remove those entries that do not have a matching file. This and the next option ensure that each file area is up to date. - Adoptions? ---------- This process is similar to the one above except that it adopts files that exist on disk but do not have a filebase entry. Using both of these options ensures that the file area is always up to date, reflecting all files that exist. - Uploads? -------- Base Runner will search through your BBS file areas and import any new uploads it finds. During this time, there are some limited processes performed on the file but Base Runner does not pretend to be an upload processor so the operations are kept to only with Base Runners filebase needs as well as some pretty intense 3 level duplicate checking. The reason Base Runner does not get too involved in this aspect is that not enough control is afforded to Base Runner unless we were online when the user was uploading the file. This way such things as demeriting the users credits could be performed. CompuData currently has one of the finest upload processors on the marked called SpotChek in release. We invite you to have a look at it to see what we mean by TOTAL control during the upload process. Besides, most BBS's have ample upload processing available to them at runtime. Please note that because the file is already in the DIR(or FILES.BBS) file, this file is not regenerated again unless you use the utility program to automatically regenerated with an implicit call to do so. We feel there is no reason to regenerate them during this operation. - Requestable? ------------ This option determines whether this file area is eligible for file requests from this area. If "N", this area won't even show on file request updates. - System Wide Duplicate Checking? ------------------------------- Base Runner has the option of checking for duplicates in one of 2 fashions and has a 3 tiered system for detecting duplicate files. Firstly, if this toggle is set to "Y", then Base Runner will check this file against all files in all areas, otherwise it will only check against files that have come into this area. The 3 tiers of duplicate checking are done as follows. - Crc calculation of filename and extension. - Crc calculation of the whole file, byte by byte(longest). - Crc calculation of file areaname. - Orig. Dates? ------------ Keep original file dates?If Yes,Base Runner will NOT change the dates of the files that enter the area. If No, Base Runner will change the date of all incoming files to today's date. - High Ascii? ----------- If you specify No here, high ascii characters will be stripped and replaced with lower ascii characters. High ascii characters are those like smooth lines and boxes. Some file echo networks don't allow them, but most do anyway. - Sort by? -------- Sort the files in this area by filename, date or none at all, whichever you prefer. - Sort Ord? --------- This is the sort order for the above, ascending or descending. Note that this option has no effect if you specify no sorting above. - Convert to? ----------- This is the compression format to convert compressed files to, if you enabled conversion earlier on. - FILE_ID Option -------------- There are three options here dealing with how Base Runner treats FILE_ID.DIZ files for incoming files. They are: Needed - Only if the FILE_ID doesn't exist, is one added. The description from the TIC file is used in this case. Always - FILE_ID's are always added, regardless if there is already on there. Never - Base Runner ignores anything to do with FILE_ID's. No description processing is done at all in this case, in other words, this is not to say that there will be no description, only that no file id file will be inserted whatsoever. Please don't confuse the echo area tic options, they are only whether or not to use the TIC description or take it from the file id. In that case, the echo areas options take place first. For this reason, the usual option here is "needed". Base Runner works optimally using the needed specifier. - Security -------- This is the security that a requesting node needs in order to see this file area in one of their lists. If their level is lower than this value, they can't request from this area and any attempt is a security violation and is refused and logged. This may be a value of up to 65534 so you have great amounts of room to expand on your requesting system. 1.2.11 Importing from PCB's Bases -------------------------- This area was selected for explanation of the Alt I, PCB import command. If you press Alt-I, you will see all the areas PCB has in it that your Base Runner system hasn't. In other words, the DIR.LST files are read as per your PCB configurations and a list is built which is displayed to you. Here you may select with your space bar any areas you wish to adopt into your file areas. Please note that the area names are built from the actual DIR.LST descriptions, so some ambiguity is bound to come from the algorythm although the greatest effort has been made to always come up with unique and original filebase names etc. There are a few commands available to you at this point. You may press Alt A to add all the areas in one keystroke. Spacebar for individual items, Page Up to take you up 15 entries in the list, control page up for 30 entries up, control page down for going down 30 entries, control page up for going up 30 entries, home works in two steps, the first will take you to the top of the page, the second , or first if you are already at the top of the page, takes you to the top of the file. By the same token, the end key works just the opposite, giving you total movement flexibility and selection control. When you are finished selecting the areas, Base Runner builds areas entries the best it can based on the info it collects up from your PCB file system, but it is recommended that you edit these areas to gain the most advantageous properties as this is a very complex and powerful file system. 1.2.12 File Area Links --------------- When in horizontal list mode, you have the usual add and delete commands to manage each record, but for file area configuration there is one more option. Highlight a record and press ALT-L. (or press the spacebar)You will be presented with the following: - Days Old -------- This specifies how many days old a file must be before it is automatically moved from this area. - Echo to Area or Hatch to ------------------------ This allows you specify which echo area this area sends new file adoptions to when it finds new files in the directory. - Move to ------- This allows you to specify where files in this area should be automatically moved to after the above Days Old value has expired. Days old and Move To deal strictly with automatic file movement. They are fairly straight forward, but there are options as to where files can go. You are presented with a pick list of your file areas, but there are two options at the top of the list that are a bit different: - Nowhere ------- This is a magic word recognized by Base Runner that tells it not to do ANY movement on this area. No automatic file movement is performed. - Home ---- This will move files "Home" or, to the file area that connects to this file. A "chain" of areas can be created so that the file can flow through your system. By specifying "Home", you tell Base Runner to move the file to the chained directory rather than move it to nowhere. With these two options, you now know that a file is considered "dead" once its owned areaname matches the current area name. By simply typing in either the name "NoWhere" or "Home" Base Runner will recognize it(case is not important) and act on it properly. Please note that these areas need not exist, they are but phantom area names that trigger Base Runner. All operations Base Runner will do recognize these "keywords" or areanames. This entire section can get a bit confusing, but it is designed with the most flexibility as possible. The best thing at this point is to explain some possible area link setups so you get the hang of it. Imagine a system with the following file areas: NEWUP30 - New Uploads 0-30 days old NEWUP60 - New Uploads 31-60 days old NEWUP90 - New Uploads 61-90 days old GAMES - Games... UTILS - Utilities GIFS - GIF Pictures Now look at the same list, but with a possible area link configuration: NEWUP30 - All new files go here first, move to NEWUP60 NEWUP60 - Move to NEWUP90 NEWUP90 - Move to "Home" GAMES - Move to "Nowhere" UTILS - Move to "Nowhere" GIFS - Move to "Nowhere" Note how files will move through the areas (30 days at a time) and eventually where they belong. The "where to place uploads" option as described above is set to NEWUP30 for all areas. This ensures all new files are posted in NEWUP30. Another twist you can add is an area called UNTESTED. I would define this as an internal private area not available through the BBS. All new files would go here first, and the area is configured to do all the work; zip conversion, virus scanning, add files, etc. The area is also configured to move files to NEWUP30 after *1* day. What happens is when Base Runner runs after midnight, all new files for the day are processed and posted in NEWUP30. The rest of the area links take the file from there. PCBoard users may use different conferences but Base Runner doesn't care about any of that. If a file area belongs to a certain conference, it's up to you to specify which upload or file area new files are uploaded to and placed in. Base Runner looks after up to 65,000 file areas and doesn't care about what a conference is. That should get you started with file area links. You can have files moved to any existing file base as you please based on the age of the file. The above is only one possible setup. You can define as many links around the system as you like. 1.2.13 Custom Headers/Footers ---------------------- As mentioned in file area configuration, Base Runner can add headers and footers to your PCBoard DIR files. There is no default for them, they are completely customizable. Included in the Base Runner package are the files HEADER.PCB, FOOTER.PCB, HEADER.ANS and FOOTER.ANS. The .PCB files are for use with PCBoard and the .ANS files are for use with RA. They are examples of how you can design your own headers and footers. Basically, headers and footers are just text graphic files much like the screens you design around your BBS. You can use any of the variety of editors out there, Thedraw, PCBEdit, etc. They can contain any kind of text you like. Just design them like you would any other ASCII or ANSI/PCB screen. In addition are special keywords you can place within the text that will be translated into various parts of your system information. Below is a list of these symbols and what they display: SYSNAME - System name SYSOP - Sysop name LOCATION - Location PHONE - Phone # FILES - Total files in a given file area BYTES - Total of all files in bytes KBYTES - Total of all files in kilobytes AREADESC - Area description UPDATE - Date the header (and listing) was created/updated FIRST - Earliest file date of all files LAST - Last file date of all files AREANAME - Area name (as defined in file area config) Anywhere in the header or footer text you place these keywords and their corresponding information will replace the symbol when Base Runner regenerates the DIR file. You may think that it's possible these keywords may conflict with ordinary text but there's one thing missing. These keywords are to be bracketed by one of 3 other characters that denote their justification. The following are the available justification characters: % - Left Justify Left justification starts where the first % character lies like so: %SYSOP% Steve Tupy @ - Right Justify Right justify is a bit different. The LAST character of the inserted string is placed on the LAST @ character. You can use this feature to ensure inserted text does not extend past the right side of the screen. ex: @SYSOP@ Steve Tupy ^ - Center Text Centered text is based on 80 columns wide and text will always follow this rule. In other words, you cannot use this character to center text between columns 1 and 40. ^SYSOP^ Steve Tupy Suppose you wanted your header to start with the area description centered on the first line. Your header text would contain the following: --------------------------------------------------------------- ^AREADESC^ Total: %KBYTES%k Files: %FILES% First: %FIRST% Last: %LAST% --------------------------------------------------------------- Keep in mind that color codes for PCBoard or ANSI can be placed anywhere in the text. The result for a given area might look like so: --------------------------------------------------------------- New Uploads Total: 32046k Files: 1035 First: 01-01-80 Last: 01/01/95 --------------------------------------------------------------- Keep in mind that you will have to leave enough room for the widest possibility. %SYSNAME% is somewhat shorter than "CompuData Systems BBS". Also remember that you can spruce up these files with ANSI color or PCBoard @ codes, as well as smooth lines and boxes. The final look is completely up to you. You might have to play with it to get used to the placement of keywords and color codes but you'll get the hang of it. You don't have to have both headers and footers and you don't have to have any at all. If you leave either or both options blank in file area configuration headers/footers will not be generated for that area. 1.2.14 File Area Global Menu --------------------- If you press Alt-G in the file area manager, you will notice a new menu popping up in front of you. Here you may do certain things globally on more than one record at a time. This allows for global editing which can save you alot of time, especially if you run a large hub system. Here we will go over the menu items, what they do and ways to optimize your use of folders. Folders are the system used to identify which records you want worked on. When you create areas in the area manager, you enter a folder for that area. You should arrange these areas into folders in such a way that they are related in some way. Some examples of this would be Fido, PCB, ADS etc. Then in one quick stroke, you can change or add field parameters which belong to the folder you selected. - Hatch To? --------- Here you can change(or add if that area is currently blank) the destination echo area this areas adoptions will be hatched to. If the area being configured is set up for auto adopt(or hatching) then this will be the areaname of the area to hatch to. FECHO.DAT will be scanned for this areaname and when found, its defaults will be used by Base Runner for such things as downlinks, uplinks etc. Everyone in this list will recieve a copy of this file when this hatching process is taking place. More on that in the specified topic areas. You will first be shown a dialog allowing you to browse and find the area you wish to hatch to. After pressing enter you will be shown another dialog allowing you to select the folder to scan for. Then all areas with this folder selected will be modified. The number of changes will be reported to you and you will then have to press any key to return back to the global menu. You are then ready to do something else globally or return again(by pressing ESC) to the viewing window. - Header ------ This applies to the field in file areas that says "Header". This is (more in file area configuration) the file that will be placed at the top of the DIR file (Or Desc) for that particular area. As above, you will have to select a folder after you enter the path and name of the new file. - Footer ------ As above except that this relates to the footer or bottom of the DIR file. - Add Files --------- The path and filename to either a single file to add to the archive or a group of files to add. See file area editing for more info on this. As above, you will be required to select a folder and will be reported on how many changes were made. - Delete Files ------------ As above except that this deals with files to delete from the archives. - Comments -------- The comment file(or line) that will be applied as the new comment for files entering that area, this allows you to change the comment file for areas in this folder(as above). - Delete Age ---------- This is the same as the Delete Age field in file area editing - Security -------- Globally alter security levels for file areas as well. - Max Files --------- Sets up maximum files permitted in file areas. - Toggles ------- These are broken down as follows... Convert,Virus Check,Dupe Check,Keep Dates,High Ascii Filter, Requestable,CdRom Area,Deletions,Orphans,Wide Dupe and Active. These are all self explanatory and are explained in detail under the file area configuration section. 1.2.15 TIC Areas(Echo Area Configuration) ---------------------------------- Inbound files with accompanying TIC files are processed by Base Runner based on what's in here. Each Echo Area you define specifies how the files coming into the system are handled and where they're placed. - Echo Area Name(Tag Name) ------------------------ Note that this has NOTHING to do with File AREA names. This is the area name for a given file echo. These names are assigned by the originator of the echo which could be across the globe. Your uplink for file echoes should supply you with a list of area names he carries, and this is where that name goes. - Comment ------- This is just a quick description of this area such as "FidoNet Nodelists" etc. It will appear in many different reports as well as through the File Manager. - File Folder ----------- Here you select which folder this area belongs to. This is for use with security as mentioned earlier. - Message ------- This is the path/name of a text file that will be used for notification of new files entering this area. This may also be called announcements. There are a number of macros supported for the text in this file. They may be placed anywhere in the text of this file and are listed as follows... - %A% Echo(or TIC) areaname. - %C% Inserts the description of this file, left justified. - %D% Filedate in form MM/DD/YY. - %E% Todays date in form MM/DD/YY. - %F% Inserts the filename. - %L% Systems City as configured in BRConfig. - %N% Your systems name as configured using BRConfig. - %O% Originating Node(Node address of system who sent us file). - %S% Filesize of file. - %T% Todays time in format HH/MM/SS. - %Z?% Special macros which MUST be 2 wide. The "Z" denotes that this is a format specifier. A format specifier will act on its command. The "Z" command tells Base Runner to use a different pad width. Each number here specifies a number of 4 char tabs to insert before description text, so to use %Z6% would tell Base Runner that when it encounters a %C% , it should now use this value as its its leadoff value, which would pad any descriptions after this by 24 spaces. (It is wise not to pad over too far or you will see wordwrapping in your announcement text). This allows you to format the text any way you prefer for your announcement message text (or template, if you will). Only capitol letters enclosed by the "%" symbols will be formatted into the text, all others will be assumed to be literal text and will be ignored. - Announcement Echo ----------------- This is the echo area tag you wish to use as the area that the message will go into. This is an area that your echomail process- or will use to place the message into its appropriate base. PCB as well as most other BBS packages support echomail tossing. Using this type of system ensures that Base Runner will work with whatever BBS package you decide to use. If you intend to announce to an area which is not to be used as an echo area but only as a local area, you must still set up this area as an echo area. It will not affect the function of the area if you do not downlink it to anyone else. - Uploaded By: ------------ This is the default uploaded by string for this area. You can put any text here you like. Placing %A or an %S on that line anywhere creates substitutes for the echo area name and system. For example: Uploaded by %S to %A File Echo Would show in the DIR file as: Uploaded by 1:229/428 to NODEDIFF File Echo - AKA's ----- Here you select the AKA or node address that you are known by for this echo. You select the number from the list of addresses in System Info. - Initial Area ------------ Now things get a bit trickier. This and the next field determine where inbound files for this echo go now and later. Say you define an echo area called NODELIST. When files enter this echo, which FILE AREA (you defined earlier) do they go to? Perhaps NEW_UPLOADS or a separate area called NETWORK_FILES. You'll be presented with a list of the file areas you defined earlier and asked to pick one. - Owner ----- This is the area that OWNS the files coming into this echo. For example, say BESTPPE.ZIP comes into the echo PCB-PPE. You have file areas defined as NEW_UPLOADS and PCB-PPE (note that file areas and echo areas can have the same name). BESTPPE.ZIP can be initially placed in NEW_UPLOADS but be OWNED by PCB-PPE. Now when the file gets to NEW_UPLOADS, it wil be moved to the right area automatically depending on how you have your file area links set up. You could simply specify PCB-PPE for both this and the above option, in which case files inbound for PCB-PPE get placed in the file area PCB-PPE and stay there. Please take note of the magic words "NOWHERE" and "HOME" documented earlier which apply to the file area "move to" field. They do not apply here. You must specify a final destination area. Only file area configuration uses those to distinguish where to move the file. - Pass-Thru? ---------- If yes, this is a pass through area. In other words, inbound files don't get moved into your file system. Any downlinks receive files through this echo but you don't keep a copy. If there are downlinks for a passthru area, their outbound attaches and files are placed in the outbound directory and sent out. Once sent, they are deleted and you don't keep a copy on your system. - Echo Out? --------- This is a secondary security area for receive only file echoes. Say you receive a national file echo off the backbone, but you cannot hatch files into that echo. Setting this option to "N" will guarantee this area will not echo files out of your system at all. - Description Options ------------------- You may select TIC file descriptions as the imported decription or you may use the description from the file id file. - Origin Line Selection --------------------- The origin line that will be used by the announcements feature for this area. Select any one of the 50 available origin lines. This is a number from 1-50 so if you change the contents of say, origin line 7 and you had 7 selected, the new value will always be used. - Keep Requests? -------------- Set to "Y", this will keep a copy of all File Manager requests submitted by other nodes. This is usually set to "N". - Keep Receipts? -------------- Set to "Y", this will keep all receipts generated for downlinks submitting File Manager requests. More on the File Manager in a following section. - Announce? --------- Should we announce files when they come into this echo? - Traffic ------- This opens up another small window that holds information about file traffic for this area. Here are the items in order... - Files In -------- Number of files that have come through this echo area. This value does not include hatched files. - Files Out --------- Bytes that have been exported or "downlinked" to other nodes from this area. This value does not include hatched files. - Bytes In -------- Bytes that have come in through this area from your uplink. - Bytes Out --------- Bytes that have been sent out or "downlinked" to another node. This value does not include hatched files. - Hatched Files ------------- Number of files hatched from your system into this echo area. This value does not include Files Out or is not include in that statistic. - Hatched Bytes ------------- Number of bytes that your system has hatched into this echo area. This value does not include the value showing in the "Bytes Out" field. - Delete TIC? ----------- This will enable the deletion of inbound TIC files. Normally this is always set to "Y". - Delete Attach? -------------- This will enable the deletion of inbound attach files. Normally this is set to "Y". - No Delete --------- Gaurantees that this area will never be packed out of the echo database. 1.2.16 Echo Area Global Menu (Alt-G) ----------------------------- When in the echo area menu, you have another sub menu available to you called the global menu. Here we will describe the commands on that menu. They are meant to simplify large changes in node configuration etc. - Add Node -------- Here you can add a node to your lists. You will have to specify which folder you wish to process, then Base Runner will add this node to all areas that belong to that folder. You will also be given the opportunity to specify the nodes link attribute, whether it is (S)end, (R)eceive or (B)oth. - Delete Node ----------- As above, except that here you are deleting a node from a folder. Attributes do not apply here as the node is being deleted as well as their attribute. - Change Node(or change a nodes attribute) ---------------------------------------- Here it is a little different. The same applies to the fact that the node is affected if it is in the folder you specify, but here the node number gets changed. The options for that node are still the same. How you would change a nodes attribute but not the actual node address is by specifying the same address for the "Address to Change" and "New Value". That way only that nodes attribute is changed. We don't know if this is terribly useful to anyone other than the large hub, but we included it to have a full spectrum of capability. - Aka --- This is where you may select the akas you wish to represent yourself as. You may select as many as you wish here. - Message Base ------------ When a file comes in, you may announce its arrival into a PCB message base. It may then be echoed out or sent out via netmail if the area is configured as such in PCB. This allows you to select that conference by reading directly from your PCB config - Initial ------- This is the initial file area the file will be placed into. - Owner ----- This is the owner(or final filearea) of files entering this area. - Change Origin Line ------------------ Same thing here except that you are changing the origin line for a particular folder only. The changes are reported and you are then asked to press a key to continue. - Announce -------- This is the announce message (containing message text with - possible macros) text file that will be inserted into messages. Please read section regarding Message , 1.2.15, for more details. - Toggles ------- Toggles are broken down as follows and are documented in detail under echo area configuration. - Passthru - Echo out - Keep Requests - Keep Reciepts - Announce - Delete Tic - Delete File - No Kill - Downlink Original for more information on these toggles, please read 1.2.15. 1.2.17 A Note about Downlinking ------------------------ It should be mentioned how Base Runner deals with downlinking. Because most systems require you to constantly repack your bases in order for you to add more nodes, it creates ALOT of extra unneeded code and slows the program down extensively. This is not the case with Base Runner. A set record size allows us to run at a MUCH faster speed but offers a set of problems when you want to downlink to more than the 250 nodes per area provided. So to get around this, once you have filled in one areas lists for downlinking, just create another area with the same name. This second area can clone the first(except the nodes) or be totally seperate, allowing you to deal with the second set of nodes differently than the first. We believe this to be a feature rather than a bug as it allows more power in your configuration. We have yet to find practical uses for it but are sure that there are some ;) This way unlimited nodes downlinked are made possible. It would be a VERY busy system who downlinked to more than 250, though, so we think this may not in fact become an issue, but we covered the bases(pun intended) anyways. 1.3.0 Downlinking and Hatching ------------------------ Downlinks are nodes that you supply files to. When you first enter the File Echo section of configuration you get a horizontal list of all the areas you have defined. Pressing ALT-L on any area will bring up a downlink list screen where you can manually add or remove nodes receiving the area. There will be two windows appear. The windows on the left is a scrollable list of the nodes you defined in Node Information. Pressing the spacebar on any node will add or remove (toggle) that node in the window on the right, which is the current list of systems receiving that area. You can specify up to 250 downlinks. Note that your uplink can go here also. Some entries are added automatically by the File Manager as it processes requests from your downlinks. Note also that a node must be defined under Node Information in order to be added to or removed from this list. File hatching is a process by which you submit a file into an echo. For example, the local net here has a file echo called FILE_REQ. It's used throughout the net for the distribution of each system's master file list. If I wanted to send out my file list to this echo, I would Hatch the file. Hatching or submitting a file into an echo is done through both the auto echo function as described earlier and using BrUtil, a utility provided for doing all kinds of things including this. BrUtil is documented here. 1.3.1 Using BRConfig, Base Runners Configuration Program -------------------------------------------------- Using BRConfig is very simple and there is but one command line switch available to you that is used as "EGA". This tells us what video mode, VGA or EGA or quiet, you like us to run the program in. This may help for some incompatible system that do not also support direct screen writes. You may also configure the video mode in the program itself. As far as the command lists available, we will go over them with some detail but need to break them down somewhat to simplify their structure. Listed in the following order... 1 - Nodes DataBase, 2 - Files(or BBS) DataBase, 3 - Echos(or TICS) DataBase. 1.3.2 - Command List for the Nodes DataBase ----------------------------------- Alt A or Insert --------------- - Adds a record to the database. The record will be automatically added at the end of editing if you select "Y" to the prompt "Save Changes?". You are put into an editing dialog where you may leaf through the fields to select and/or input the various data items you will need to edit the node that the selection bar was on. There are two fields, or at least they appear to be input fields that are not fields at all. These are on the screen to indicate that there is "More..." when you hit that portion of the editing. Rather than clutter up your screen, certain specific items were grouped together into these "sub" dialog boxes to give you a clearer view of what exactly you are editing. When you see the new box pop up, you may cursor through th fields but there are two you may not actually edit. These are the Total Kbytes and total file fields. These are actually not fields but rather the totals calculated from the existing totals. Change one of your total values and watch these two fields adjust themselves. So with this, it is easy to explain to you that there is no editing and any attempt to "get" to those fields will fail. Alt D ----- - Deletes the current record from the database. The record does not physically get removed but rather "tagged" as deleted. When a record is marked in this way as deleted, the color of the selection bar changes to indicate the deleted status. The records do not get physically removed from the disk file until you use the "Pack" function(explained shortly). Alt G ----- - Invokes the Global menu. Here you may do various operations on a global basis, making large edits much easier. Please read the section covering the global menu for more details. Alt H ----- - Shows a help screen with this command summary on it. Alt L(or spacebar) ------------------ - Invokes the uplink list editor. A list of up to 15 lists may be edited here by simply moving the cursor to the desired selection and pressing enter. Dots will appear as the background to the editing field to indicate that you are actually editing the field. If you press the spacebar or a key before any other cursor keys, the field will automatically be blanked out and the character you used is now the first entered character. This can work for you or against you but getting used to it will aid you in becoming a "power" user. Alt P ----- - "Packs" out the database possibly removing records marked for deletion. Keeping a lot of deleted records can actually slow down Base Runners operation as the fewer the nodes it has to maintain the better. This is not, however, usually much of a problem unless you have more than 5000 nodes on the average in your database. Alt S ----- - Search operations. You will see a box pop up. If you have already entered a value prior to this execution, that value is the default. This makes repeat searches quick. Pressing Enter will accept the default value or you may edit a new value which will become the new search criteria. This value is used to compare against the sysops names in the database. Alt X ----- - Immediately exits the program unconditionally. All files are saved and you skip returning to the main menu, you are dropped to DOS immediately. Regular Ascii Characters/Numbers -------------------------------- - You may also press any letter or number key to quickly jump you to the first record of that letter/key. If an sysops name starts with "A" as in Andrew, pressing the letter A will put you at the top of the "A's". It is usually very easy to page or control page to the desired record using both of these methods allowing very powerful editing features. - Command List for the Files Database ----------------------------------- Alt A ----- - Adds a record to the database. You will be automatically put into editing mode and will be able to input to any field you wish. Please read configuring Base Runner for more details on these fields and what they are for or simply press F1 at just about any prompt for a complete help system. Alt D ----- - Deletes the current record from the database. As with the nodes and echos databases, the record is not automatically deleted but rather marked for deletion. Pressing this key again will unmark a marked area reversing the above. The records do not actually get physically removed from disk until the Pack operation has run its course. Enter ----- - As with all the databases, pressing enter will always put you into editing the current selection. This input screen will be the same one you will see for adding areas except that the current selections area values are loaded up as the defaults. Alt G ----- - Invokes the global menu. There you may perform various operations on the database possibly affecting many records with the same default value. Please read section on the files area global menu for more details. Alt H ----- - Shows the general help screen. Here you may browse the command summary. More specific help topics are available in the specific fields editing dialogs as you need them. Alt I ----- - Imports from PCB bases. This very powerful feature has to be set up in order to run properly. A valid PCB envoironment variable must be found in your envoironment. For networks, this must be a regular DOS path, not the specific networks pathnames, for example... //NODE-1//D-DRIVE// . This will not be recognized by Base Runner but E:\PCB will be recognized. This directory is scanned for PCB's configuration files and if found, your DIR.LST files are scanned for all your configured areas and only the areas not already in your database are shown on the screen for you to select. You may select as many or few as you like for importing. The DIR file spec is the field used to compare an area to see if it is already in our database. The new areas are created using as much of the information that is available as possible from the PCB configuration. You will have to still go in and edit specific information on these newly created areas. Afterwards, your database is rebuilt and reloaded and you are back in editing mode with these new areas at your fingertips. Alt L (or SpaceBar) ------------------- - Pulls up the links dialog. This is a box with some editing fields in it. These fields are also available in the main editing window but are available here as an aid to those "quick and dirty" edits. Only links information is included here. Alt S ----- - Search Operations. As with the nodes database, this feature can be used as a repeat search by simply pressing enter to accept the default you had already entered, or reedit a new value into the field and press enter, making that the new default. This value is compared against the area names for a match and if found, you will be taken to the found record. Alt T ----- - Invokes the "File Movement Trails" dialog. This is a handy way of monitoring the chain of file areas that this area is connected to. All records are scanned for connections via the "move to" fields in your files database. File movement and the areas that are in a particular chain can be quickly spotted. Only from the current selection down is included in the list. If an area feeds this one(many areas may in fact do that) it is not included in the list, only from this one until its final destination point or an area with the "NOWHERE" field. Either one will stop the "linking" process. Up to a maximum of 1000 links are listed. Be careful of infinite loops, a group of areas that are going in a circle. This command helps you in spotting those types of problems. Alt X ----- - Unconditional Exit. All configuration files are properly updated and closed and you are immediately dropped to DOS. Regular Ascii Characters/Numbers -------------------------------- - You may also press any letter or number key to quickly jump you to the first record of that letter/key. If an area name starts with "1" as in 1-BUSI, pressing the number 1 will put you at the top of the "1's". This is the same for any keyboard letters. It is usually very easy to page or control page to the desired record using both of these methods allowing very powerful editing features. - Command List for the Echos Database ----------------------------------- Alt A ----- - Adds a record to the database. You will be placed into an editing dialog and there you may input the data fields. Each of these fields have help by pressing F1. Alt D ----- - Deletes the current selected record from the database. The record is not physically removed from the disk until the Pack operation has ran its course. The record will change color on the selection screen to indicate that this selection is now marked for delete. By pressing Alt D again or on any area marked as deleted will reverse the mark and undelete the record. Of course, you cannot undelete records from a packed database. Enter ----- - Edits the current selection. Here you may input or change values for the current selection. The same input dialog is provide here as when you add a new record except that this areas defaults are all in their proper fields. Alt G ----- - Invokes the global menu. There is a variety of global database changes that you can use from this menu. The operations on this menu are explained in more detail in the configuration section. Alt H ----- - Shows a screen with a command summary similar to this one. Pressing escape will abort this dialog. Alt L ----- - Allows viewing/editing of current node connections to this echo area. Here you may add or delete nodes or change their link status. Alt P ----- - Packs the database permanently removing the records marked for deletion. You are prompted and may turn back after pressing this command. Alt S ----- - Search operations. The field that pops up in the dialog that shows up when you press Alt S that has the default search string in it. Pressing enter accepts the default and the search is taken up from the location you are at in the database. You must go to the top if you want to scan the whole base. This default value aids in repeat searching. Alt X ----- - Immediately cleans up the configuration files and exits the program unconditionally. Regular Ascii Characters/Numbers -------------------------------- - You may also press any letter or number key to quickly jump you to the first record of that letter/key. If an area name starts with "1" as in 1-BUSI, pressing the number 1 will put you at the top of the "1's". This is the same for any keyboard letters. It is usually very easy to page or control page to the desired record using both of these methods allowing very powerful editing features. Edit Fields Pointing to Text Files ---------------------------------- - Most of these fields support an F2 command which will, if configured for an external text editor, will invoke it allowing you to directly edit these files. Please note that with fields that do no begin with the % symbol (which denotes only a single file or comment) will be ignored by this command. It will only work on valid DOS files. No checking is done for binary or text mode during this shell. 1.4.0 BRUtil - Base Runners Utility Program ------------------------------------- A Utility Program called Brutil is included in the distribution archive. This program is designed to do all of Base Runners maintenance events. There are two ways to invoke BrUtil. One is via command line(registered copy only) or you may use the interactive version with an easy to use menu system and built in help system. Please note that although the command line version is fully documented here, it is not available in the evaluation copy. To invoke Brutil you may simply type in the name of the program or run it from the command line. The command line version is only available in the registered version but is covered here. We will go through it from the top down in the main menu of the program. You may use your mouse to navigate through the menus. The only time the mouse is not active is during input operations as in Hatching, Notifying etc. In the command line version, you can string as many commands together as you like provided they do not exceed 127 characters in length in total.If this is the case, you will have to invoke it again with the new commands. An example would be... BRUTIL INDEXES PACK NOTIFY NOKILL ..... BRUTIL DELETES ... 1.4.1 - Pack FileBases -------------- This instructs Base Runner to read your index file one at a time for each area and copy its attached record from the main base into a temporary base in order, skipping the deleted records and compressing your bases reclaiming disk space as well. The fallback to this operation is that you can no longer recover lost records by rebuilding the indexes. This happens due to programs like Base Runner deleting records indexes but not the main record in the base. We did this purposely to allow data recovery options in the future and to allow more flexibility in the function and use of it. Of course this requires you to know a bit more about what is taking place with the package but will afford much more power overall. Command Line Syntax... BRUTIL Pack (case is not important) This operation is not quite as quick as the others as it is the most disk intensive operation in BRUTIL. Please note that if you are trouble shooting a corrupt base, this is NOT the first course of action to take.Please read section on FileBase Troubleshooting. 1.4.2 - Build Indexes ------------- The only time you would ever need to use this feature is if you were trouble shooting a problem with one of your bases or if you wished to recover some deleted files. In either case, the command line syntax for this operation is ... BRUTIL INDEXES (case is not important) This operation will go through the filebases one at a time checking each record and recreating an index for that base. Note that you will now have possibly many more files in your base than when you started because the main Base Runner program , when deleting records, deletes only the index record, leaving a "hole" in the filebase. The trimmed index is lost in lieu of this newly created one but if in fact you had a corrupt index(an index is corrupt when BREDIT shows nothing but garbage and possibly locks up when in an area) this is favorable because you can now delete the records instead of losing the whole base. A few examples of why you would need this feature are power loss with a disk cache running, disk fat problem, network crash etc. 1.4.4 - Duplicates ---------- Because some files come through more than one file echo sometimes, it is hard to define what is and is not a duplicate, so with Base Runner, a duplicate can only be defined on a binary scale. This means that simple filename duplicates are not enough. We must also include a binary representation. There is a way to check each character against a table to see if it is the same as another file. This CRC type of calculation on a file is a very good method and although it may take a little bit more time, it is well worth the security you attain by using it. One problem, however, is that even an identical file may be sent(as mentioned above) to two different areas. Because of this, only files that share a single base that are identical are checked by Base Runner to ensure proper operation. This feature of Base Runner goes through each base and if it finds both an identical filename and an identical file on a binary level, it will remove the oldest copy of this file. If more than two exist, the newest copy is maintained. The arbitrary system used here is only to accomodate the command line nature of this utility but will not be limited in further consideration of how this operation should be handled. Command line syntax ... BRUTIL DUPES 1.4.5 - Dupe Trim --------- There is a number you may specify in the configuration program under System Info for the number of dupes to maintain in the database. Since this is not a critical routine, an event periodically will suffice in maintaining this base. The base is trimmed to the number in the config. Only the latest x files are kept. The rest are lost and are not recoverable. 1.4.6 - Notify List ----------- Available in both modes of operation, this command tells Base Runner to go through each of your node entries and if they are toggled for notification, they will receive a netmail message generated with the default message flags you specified for that node with the areas they are configured for. That way they may compare that list with their own to see if they have a current configuration or a configuration that is identical to yours. Command line syntax ... BRUTIL NOTIFY 1.4.7 - Hatch File ---------- On the main menu of BRUtil you are prompted for a path/filename to hatch, followed by a file to replace(optional) and then you are asked for an area to hatch to.Base Runner will then go through your areas until it finds the file you want to hatch. If it is found, it is file attached to all nodes that are currently configured for that area. The packet status is set to what you have set up for each particular node. An accompanying TIC file is sent along with the attach file to that node with all the info needed for that node to process that file into that echo. Your password is included in that TIC file so be sure your passwording is set up properly before using it. Please consult with your local hub for info on whether they wish you to use TIC passwording.This is a personal preference but is comming into use more and more as security becomes more of an issue. In the command line mode, the syntax for this feature is ... BRUTIL <PATH/FILE> <AREA> (no brackets, case insensitive) - presently ,the replaces field is not supported in the command line version. 1.4.8 - Send File --------- This is similar to the above feature in that it sends a file to a downlink. There is one difference here. This operation does no checking to validate a node, it simply does what it is told, sends that file (if it exists) to the node specified and does not warn you if the node does not exist. This is intentional as Base Runner assumes you want this ability and will not bother you much about it. Please note that because this file is not being "hatched" nor echoed, it will not have an attached TIC file with it. On the main menu, you are prompted for a filename and then a node number. In the command line mode, the syntax is ... BRUTIL SEND <PATH/FILENAME> <NODE#> ... node number can be any node number as long it is a valid format and filename must be a valid path and file or Base Runner will drop out and let you know it was not succesful. - Get+ --- A very handy utility for "fetching" files from another system, whether or not they are in your nodes database. The syntax is as follows(if you are registered user with command line)... BRUTIL GET <FILENAME> <Z:N/N.P> <PASSWORD>(optional) ... node number must be a valide Fidonet address(point number is optional) and the password is optional. This does not update the nodes database with file stats as it is considered to be a "Raw" utility to aid in those times when "Quick & Dirty" is the matter of business. 1.4.9 - Init Bases ---------- This would usually only ever be run once, but was left in this utility program because it was thought that once a new area was created, you may want to go in and readopt the area into your filebase. This feature will go through the DIR files specified in the areas configuration and recreate your filebases with the descriptions found in the DIR file. Some other info is processed such as the CRC of the file but no file adds, file ids or any other processing is done. This is for speed reasons and because you may not want all your files on your system reprocessed. You may also use this feature to bring a new area into your Base Runner system that wasn't there before. For example, you already have 20 areas on your system, but you want to import and start using a few more. Simply set up the areas for them with the new directory and DIR file name in BRCONFIG and then go into BRUTIL and run this operation. Please note that this may take a long time depending on your machine type, number of areas processed, number of files processed etc. Whatever you may have had in any existing filebases are lost permanently after this feature is run. 1.4.10 - Build CRC --------- This will go through each of your areas and build a CRC table of your files and add them to your duplicate database. This will, of course, delete any existing file info you have. The reason for this is if you lose your dupebase or corrupt it in DOS for whatever reason. This way you can quickly come back and re-build all the files that are on your system. 8 bytes are stored for each file that is in the base, so size should not be a large problem, but if it is, you may go into BRCONFIG in system info and change the dupe limit to reflect a lower number which will save some disk space, exactly 8 bytes per file managed. This base is automatically trimmed by the Trim feature, so after you have a valid base, you should never have to run this operation again. 1.4.12 - Auto Unlinking -------------- Sometimes every node will unlink themselves from one of your areas and you will not notice that you now have an area hooked up to your uplink that may not be necessary. What this operation does is generate a message to your uplink disconnecting you from that area so that it is now a "dead" area. The record is marked as deleted but NOT removed from the database, you can do that with the "Pack" routine in BRCONFIG's editor. That way you can also see which areas have been removed. This can of course be overriden so that it remains connected by setting the appropriate toggle in the main config using BRCONFIG->File Echos->Edit->No Kill, which will override anything this operation may want to do. 1.4.13 - About ----- This is just some information about the program, copyrights, mailing address for CompuData etc. It is of no importance other than to flag the program and its copyrights without having to pester you with it all over the program. 1.4.14 - History+ ------- A very handy report that includes all the information you need about file activity. The number of days specified in the main configuration is used. The reason for this is that the file is automatically trimmed to that number of days. This command is available only from the command line and not in the main menu; 1.4.15 - Dirs ---- Sometimes if you make changes in BREdit or if you are not happy with the formatting of the DIR file or for whatever reason you might have, this feature will allow you to regenerate either one or all of the filebases for the BBS (either the DIR file or the Files.BBS file). In the full screen mode you are guided through the inputting of the areaname to regenerate (if just one area) after which the area is recreated and placed into the specified directory for that area. In command line mode you must enter the syntax as follows... BRUTIL DIRS OFFLINE or you may also use the magic word "ALL" to denote that you wish Base Runner to regenerate all of the DIR files(or Files.bbs). BRUTIL DIRS ALL How long this process takes depends on how many file areas you have. Also, all the headers and footers are regenerated accordingly, so if you made changes to those files(the templated text files with the macros in them), they are regenerated at this time. If you simply made changes to the final header or footer and not the original template file you do not have to regenerate the attached file areas DIR file. The reason for this is that the DIR file only uses the %PATH/NAME to point to the generated file in your headers directory and does not include the actual parsed text. 1.4.16 - Exit to Dos ----------- Drops you back to the operating system giving full control back to the calling batch or command line. Cleans up its config updates before it exits. 1.5.0 Using BREDIT, Base Runners FileBase Editor and Utility System. ────────────────────────────────────────────────────────────── Base Runner Edit or BREdit for short, is Base Runners Filebase editor/utility program. It is very much like PCBFiler only for the reason of familiarity. We are not here to alieniate PCB sysops, we try to blend in as seamlessly as possible, so the interface is as much like that program as possible and is in no way intended to "Rip off" Clark Developments PCBFiler program, only to try to emulate it, well.... almost .... as you will soon see... we have a few extra things we think you will enjoy. Such things include a full two way file id system. This means that you can insert a file id file from the archive into your filebase as the description, hence the generate DIR files will have the file id file in them as well. The other way is to take the description currently in your filebase and insert it into the archive as the archives new file id file, replacing any existing file with your new copy. Move, Copy, Delete, Hatch, Edit, DateStamp, Abandon and Viewing are just some of the features of this very powerful editor. Now we will go over the main function of the program with the system requirements first, stating how much of the config is necessary before proper operation is obtained. A very handy interface with very elegant colors and fonts are provided and full mouse support makes this a very easy to use system. 1.5.1 - Requirements ------------ You will have to make sure you have properly configured Base Runner before you may use this program properly. Fist, you must have valid Files Areas defined with valid paths (config will let you know while editing if the path is not valid and prompt you to create it if necessary). Also , you MUST have a "BAD_FILES" record so that any failures in the file processing will ensure BREdit can move the file offline to this area. A valid filebase path in system info and a valid filebase path for each of these areas must also be defined if you wish to find the data files for that area. You might also want to make sure that you have an editor defined in BRConfig (system info->Paths). You may specify any editor that takes a filename on the command line. Other than that you are on your way. - Initial List Dialog ------------------- This is the initial entry point in the program. It supplies you with a list of your file areas. You can be anywhere on your system as long as this program is in your path, so these areas files can be found because they must remain in the home path of the program, or reside in the same directory as BREdit. This list box has full mouse support so that all you have to do is point and shoot, or you may move your cursor down to the area you wish and press enter. If you are using the mouse, you must press enter once to drag the hilight bar on top of the area name and then a second time to actually tell BREdit to load up that areas indexes and display it and then leave you in edit mode. Whenever you exit an area, you are placed back into this dialog so you may select the next area or press escape to exit or the right mouse button. 1.5.2 Command Summary/Status Bar "Hot Spots" -------------------------------------- - Alt A - Add File Id File ------------------------ If the hilight bar is on the selection you wish to operate on, you may press Alt A or if your mouse cursor is on the the Alt A text on the status bar, you may press the left button to invoke file id addtion operations to that file. Please notice that it does not just "run right in" and do it, it simply marks the record for that operation. You will see an "A" on the left side of the files box. This operation will be performed when you try to exit tihs area. At that time you will be prompted on whether you wish to save your edits or not. This operation will take the description you have entered and replace whatever file id exists in the archive with it as a valid file id file. If one does not exist, a new one is added. - Alt B - Abandon File -------------------- If you wish to delete a filebase record but NOT remove the file from disk, you may abandon the file. The actual file that this record belongs to is removed. Please note that if you do this and the file area is set up for auto adoption, this file will be adopted into this area automatically the next time that the main Base Runner program is executed again, making this edit useless. The reason for the adoption is so that in case other programs simply "COPY" files into that directory, we can immediately pick them up and put them into our filebase for that area, making this a "real time" , static style files system which is current up to the second. - Alt C - Copy File ----------------- This will take the filebase record AND the file and copy it to another area. You will be prompted for the area to copy it to with a dialog box of areas available similar to the main file area dialog box so that you may select which area to send it to. You will see a "C" on the left side of the screen appear signifying the area number that this file will go to. There is not enough room for the areaname, so the number will have to do for now. - Alt D - Delete File ------------------- This is similar in function to Alt B, abandon file, except that with this operation, the file is deleted from disk as well. BREdit does not handle file recovery or undeletes(yet!) so be sure you want to delete this file permanently. - Enter - Edit File ----------------- A new dialog box appears if you press either that area of the screen with the left mouse button or the Enter key. You will by default be in the description editing window. This is because the speed users will want the fastest way to get to the text editing window. The filename and the filedate may also be edited here. A very simple full screen editor is supplied although we are considering allowing "Plug in" editors for this purpose, allowing you to plug in such editors as Qedit(C) so that you may be more comfortable with your editor. There are a couple of new commands available to you in this dialog. - Alt I - inserts a blank line at the point of the cursor. - Alt D - Deletes the current line. - Enter - Splits the current line if not on left or right. - Escape- Ends edit session, you are prompted for save. You may also edit the filename or the filedate. Move your cursor to the field you wish to edit and simply edit the field. This is all keyboard input, there is no mouse support returned again until after you press the Escape key. Please read 1.5.3, Editing a file entry for more information. - Alt F - File Id Add ------------------- This will instruct BREdit to take the file id file, if one exists in the archive and inserts it as the new description in the filebase for this entry. The DIR files are not regenerated until the next execution of Base Runner, so it is a good idea to run Base Runner through after edits of this nature are done. In future versions, this will all be internal to BREdit. - Alt H - File Hatch(+) --------------------- You can now hatch as many files into as many areas as you like right from BREdit! You can even hatch all selected files in one quick step to one area at a time, making this a VERY powerful feature of BREdit. You can also hatch from DOS with BRUtil. When you press this command you will be prompted for an area to hatch this file into. If you had more than one file tagged or selected, you will first be prompted whether or not you want to hatch THIS file ("N") or all selected files ("Y"). If you select all files, BREdit will prompt you for a file area and once selected, all files tagged or selected will become unselected and they will now become marked as H<areanum> on the left side of the edit window. Afterwards, when you exit the edits for this area, you will then notice the actions BREdit takes to hatch the files out. It will create an attach message and an appropriate TIC file to all the downlinks and uplinks currently connected to this area. BREdit will also mark the file as NOKILL so that it cannot be moved until after it has been sent out to all the nodes currently set up to received it. After all nodes have received the file, the next running of BRUtil NOKILL will clean up the no kill markers on these files. - Alt I - Info ------------ This will bring up a dialog box with some important information about this areas setup. Here you may see such things as Dos Path, Message Base Path, Add File Path and Name, Delete FileName and path, Days Old before files will be moved, where to upload files for this area to and where to move files after Days Old has been reached. If you are confused about what any of these do, please look under BrConfig for more details. - Alt K - No Kill --------------- Marks the file as No Kill, meaning it will not be moved nor processed in any way until this flag is removed. Normally Base Runner will deal with this flag internally and should not normally be used by you, but there are times when you need to toggle this so it is available. If you have any files selected, you will be first prompted to see whether you want to mark just this file or all selected files as No Kill, you have the option. You can leave all the selected files selected but just mark this one or you can answer "Y" and mark all files selected in one quick keystroke. Left mouse button is the same here as pressing "Y" or Enter during this prompt. - Alt M - Move File(s) -------------------- You can move files around the areas quite easily using BrEdit. You can move just this file or all selected files exactly the same way you do with copy except that this does not leave a copy of the file in this base, only a copy in the destination base. You may still abort this operation when you exit from this areas edits by pressing "N" to the "Save Edits" prompt. Escape or the Right mouse button will do the same thing. Please remember that unlike PCBFiler, these files are moved right after you process this area. - Alt N - No Show --------------- When the DIR files are generated for your BBS, you can choose to skip showing all of them by setting this toggle on for the chosen file. This file will then not show up in the PcBoard's file areas but will actually still be there in the directory. - Alt O - Owner ------------- Normally, when a file comes into the system, it will have a default behaviour connected to that area. The problem with having just this is that it is not flexible enough. You can mark files seperately here with alternate ownership. This means that a file normally marked as "PCB-UTIL" for ownership, which would normally send its files after 30 days(this is all example) to OFFLINE that is now changed to "PCB-QWK" will now go to that area when it is done (OFFLINE) but when it is finished going through the areas(or if it comes into an area that sends all its files HOME) it will then wind up in "PCB-QWK". Please don't confuse this as the NEXT area the file goes to. The file will still go from here to the next base this area sends it to but when the file gets to the last directory in the chain, that base should become its home. - Alt S - Select -------------- This will "Tag" or select the current file. You can select as many files as you like for use with other features such as Copy, Move, Hatch, No Kill etc. If the file is already marked, it will be unmarked, if it is not marked, it will now be marked. You will see an "S" on the left hand side of your screen beside this files entry. Pressing the left mouse button on the status line on all items will activate that command. Exiting edits for this area will lose all selected markers. - Alt T - Touch FileDate ---------------------- You may "touch" or change the filedate of the file without having to go into the edit window if you want to change the files date to todays date. This is known in DOS as "touching" the file(please consult DOS manual under touch). You can also change the file back to the original date if you have not yet exited the edits for this area if you change your mind. The reason for this is that we actually store two dates while in edit mode on each file, so the original is still maintained and can be restored but be warned that after you leave this base you will not be able to undo a touch. - Alt V - View Archive -------------------- This will activate an archive viewer which will look into the archives, if this is an archive and list the files in the main file window of this archive, prompting you to press enter after each screen full of files and then one final enter when the last screen is done, returning you back to the main edit window. - Alt X - Exit Program -------------------- This instructs BrEdit to exit immediately, NOT to go back to the main area selection dialog. BrEdit will not perform any of the edits and you will lose them. You may also press the litte square yellow box on the main edit window borders right side to exit immediately. - Other Commands -------------- There are four arrow keys on the right hand box border. These are "hot spots" for your mouse cursor to use. If you press the left button on either of the inner arrows, you will scroll up a page or scroll down a page of files. If you press the outer arrows, you will go to end or home and the same behaviour as the home or end keys will kick in. The home key when first pressed will take you to the top of the current page of files but if you are already on that top line,you will then be taken to the top of that areas list. The end key works the same way,if you are not on the bottom line, you will go to the bottom line, but if you are you go to the bottom of the database or list. 1.5.3 Editing A File Entry -------------------- There are a couple of things to go over here, as well as some minor gripes ;) If you press Enter, as mentioned briefly above, you will see a new pop up with some items in it. Your cursor will automatically be in an editing window, pressing any key on your keyboard will affect the description for this file. You may edit just as you would with most editors, but please understand that this is a *very rudimentary editor and is not meant to be a power editor such as some of the markets finer editors are. It is with that idea that we allow you to use whichever text editor you feel comfortable with, so long as it allows Base Runner to pass a file name to it on the command line. Edit.com that comes with DOS is a good example of such a program. If you use one of these editors that allow you to use such commands as "Save As", please use the default of temp.dat as the file name. In other words, please just save the file and not necessarily save it to an alternate filename. In order for an external editor to work properly, one must be declared in your config program, BRConfig, under system info and under paths. There you will find a field called Ext. Editor. This field takes only the name of the editor(along with the extension of .exe if you wish, it speeds up Base Runner) and not the full path.If you have room and wish to put the path, that is all right too, but we suggest you place the editor in your path and let us find it for you when we need it. You will be prompted on whether to save the new edits or not,but only if you have made changes to it. Base Runner is smart enough to know if you have changed the description file as long as you save it to our default name of temp.dat. That takes care of the external edit, except for one thing. If you want the extra editing features of the editor that is internal, you may wish to still use the enter key to get into that section. There you may edit the filename, filedate or even the date the file entered this area via a file movement. Status is shown on the left hand side for the current file. 1.6.0 Introducing Base Runner File Request System or BRFREQ ───────────────────────────────────────────────────── - Description of File Requesting ------------------------------ File requesting in this concept is totally unlike the commonly referred to term of file requesting. Unlike Fido style file requesting, this is not intended for sysops to exchange files via their mailers. This is a system that does in fact use your mailer or front end, but uses it to transfer files back and forth for the benefit of your users. There are many ways to attack this type of situation and we are constantly changing this facet of the package, but at this time it is a one tier system with direct node to node contact, no hubbing is necessary. Because of the nature of this request system, hubs are not needed and may in fact hinder the efficiency of the overall system. Ok, enough of that, lets find out what this is all about. If you and another sysop or sysops wish to have their users have access to all the participating systems file areas via an online door, all you need to do is specify that node in your configuration as file requestable, set up a couple of simple things to accomodate the file flow and you now have an automated system for your users to request files from any other BBS involved. Setup is a breeze and you can limit other systems amounts or just put a cap on what they can take daily to keep a "lid" on how much is going out. In more technical terms... BRFreq is designed to allow your users(and you as sysop) to request files from other systems. Only systems found in the nodes database may participate. Users and/or sysops of these systems may only request from your BBS areas (File areas) , not from TIC (echo) areas as these areas are only to point to an existing BBS area anyways. Each generated netmail message to that system has to have a valid password on the subject line. One file per line must have the format of .... REQUEST <AreaName> <FileName> ... on it. At any time in the netmail message there is a tear line(---) found, the message parsing is aborted and nothing after that is processed(handy for notes etc...). This format of generated netmail message is by default created by BRFREQ when you "flag" files from the board. When a user enters the door, the door first looks up all netmail messages and puts existing requests from that person back into its batch queue. It then removes those messages from netmail area. When the user has finished flagging or editing his/her batch of files and tries to exit the door, they are prompted on whether they wish to send out the requests they have generated. If answered with a "Y", then BRFreq regenerates the necessary attaches to the various systems, providing appropriate passwords. You will find also a LIST <Julian Date> line in each of these messages. This date tells the other system the date of your last list update. If this date plus the list delay in days is found to be less than todays date, a new set of lists is generated for us and we then not only recieve the files we requested but perhaps also an update if the above criteria is met. You may also force an update by putting in the line of UPDATE anywhere in a netmail request. The file is then returned to us via regualar file attach, but only after they decide that we have not taken more than we are allowed for today. When the file is returned to us, we scan the netmail headers in the request routine and find the message. We then toss the file into the filebase area specified for that node. If a seperate area exists for that node other than your regular file areas, only files marked as user requests will reside in that area. An optional announcement may be posted if configured into the echo area tag specified for that node. The other node, meanwhile, is keeping track of all bytes and files they sent us and if at any time we exceed our daily allowance (or 0 for unlimited), we will not get that file back. After midnight, our node stats are reset and any new messages waiting will then be processed again and sent out to us. This causes a possible backlog of requests but is the only way to restrict access to a node taking "too many files or too many bytes". That is the most technical way of explaining it. Please remember that although this is primarily designed for users,sysops may also generate request from their favorite mail editors, provided the syntax is followed for generating such a message. 1.6.1 - Installation and Setup ---------------------- Installation was partly complete when you initially configured your total Base Runner system, but some things need to be addressed at this point. We will put this in point form for simplicity and clarity. 1 - Make sure each node that is going to participate has a node entry in your nodes database. That entry must have file requesting toggled on (you will notice the edit fields are darkened if file requesting is NOT activated systemwide from within System Info->Global Options). 2 - Make sure that the directory in the nodes record is a valid path. The config program will prompt you if you wish to create a non existant directory. 3 - Make sure the nodes entry has a system name so that BRFREQ can have a system name to display to the users. 4 - Be sure each system has a password set up. 5 - Send out a first intialization message to each system with the proper password on the subject line and the lines ... UPDATE --- as the only text in the message.Anything after the --- is ignored. This will initiate the request to get the updated lists from that system. From that point on, list updating is automatic with every request issued. 6 - Run your PcbSetup program and install a door entry into your DOORS.LST file on your PCB system. Consult your PCB manual on door installation. Specify the door to create a USERS.SYS file. Edit your batch file (which at this point is still just a script until it gets renamed by PCB at runtime) to make it look similar to the enclosed BRFREQ sample file or you may use the BRFREQ file with some edits to suit your system, number of nodes example. 7 - Make sure that your nodes are setup to security properly. For example, if they have a security of 50 and most of the areas are set up for 75, they will not see most of the system and will only receive areas they have security for. Folders do not apply in this situation. This security level is the main thing to consider in allowing access. 8 - Test the door, make sure all the lists are accessible, if not, check your paths to see if you have the lists there and the control file. This control file is automatically included into a ZIP when you receive the bundle from the other system. The main program deals with all of the operations necessary to handle the complete file requesting system. If the door simply locks up, try specifying no shell in PcbSetup. We have found a couple systems with limited memory have problems running under PCB when trying to run some doors. This is supposed to be fixed as of v15.2 of PCB, we have not seen it yet. 1.6.2 Configuring BrFreq ------------------ - BrConfig-> Requesting --------------------- This is where you set up your screen paths and filenames and a couple of general system toggles that deal with file requesting. This section of the Configuration program was put here as it directly related to this part of the package and did not need to clutter up the main configuration options. Besides, this area is quite small and easy to isolate and deal with. - Paths/FileNames --------------- - Path/Filename of Intro Screen ----------------------------- This is the path and name of the first screen the user will see after the copyright notice. There will be a delay to the user after this screen of how ever many milliseconds you setup in the following section. You may use PCB macros in this screen or any ANSI sequences as well. RIP is not supported at this time but is currently being worked on. A sample screen is included in the distribution archive. - Path/Filename of Main Screen ---------------------------- As above, but this is the actual main menu you wish the user to see. This should include any menu commands that are available to the user. For more information on these commands, read section on using BrFreq. A sample screen is included in the distribution archive. - Path/Filename of Bye Screen --------------------------- As above, but this is the last screen the user sees before returning to the BBS. As above, PCB macros may be used in this file and a sample is included in the distribution archive. - Path/Filename of Help Screen ---------------------------- Same deal here, except that this screen should include information about the functioning of the system, available user commands etc. A sample help screen is included in the distribution archive. - Milliseconds to Delay after Screens ----------------------------------- 1000 milliseconds equals 1 second in real time, so this allows you total flexibility. We were going to do it as simply seconds but found that it was not enough control so we went down to milliseconds and found that it gave us the ability to customize the feel of the system. On screens that are scrolled this has no effect. This is used after the intro screen and after the bye screen and after certain non keystroked prompts. 1.6.3 Using BrFreq ------------ You will notice a familiar look when BrFreq is running. The status line and controls are very similar to PCB itself. You can drop to dos with the F5 command as well as F10 for chat. The F6 and other system critical routines are not available. The program all runs off of a main menu which loads up a default system, usually the first one at the top of the list and shows it as part of the main menu command prompt. There are a set of commands that are available to the user at this point. They are listed as follows ... - "B"atch Editor -------------- Your users upon entry into the program have a batch built in memory of the files they themselves have perhaps already requested. This information is collected up by BrFreq upon start up of the program and is in memory until the user quits back to the BBS. At that time, the batch file is inserted into a file request message to the various requesting systems but only if the user answers "Y"es to sending the pending outbound requests. The user sees a new sub menu and has a list of all the existing file requests. The user can press "D" for delete entry at which time they will be prompted for the number of the entry to delete. They can also add a file. This command has a little twist to it. It will not be limited by searching only the current systems files areas for the files requested, they will search ALL systems filebase files for the match and create the necessary request to the appropriate system upon program close. The add file command is activated by pressing "A". - "S"ystem Select --------------- This allows the user to select from a list of systems to request from. The user can only be "logged on" to one system at a time. When a system is selected, the control file, AREAS.CTL is loaded up for that system for speed into memory. Most commands deal with the current systems areas in mind, so to access another systems file areas, you must select another system again. All commands refer to the current system only except the batch editors add command, it has a global searching mechanism. - "G"oodbye/Logoff ---------------- This instructs BrFreq to logoff the user immediately. All requests are cancelled and not processed as it is assumed that if the user made such a drastic move as request to log off and not just quit to the BBS then they must not want to send out the existing requests. - "F"iles Listing --------------- This will take the user to a selection screen to select the file area they wish to view. When they are scrolling through the listing once they have selected their area, at the bottom of each page full of files they receive a one line prompt with a couple of items available to them. "Y" or Enter will simply continue on with the listing clearing the screen first. "N" will abort the listing and drop them back to the main menu so that they may continue with other commands. "F"lag allows them to select a file that they see for request. If they enter some valid input, the current file area is rescanned to see if it was a valid filename from this list. If it was, then it is added to the list in memory(that batch list we talked about above) along with the system name, password etc and the user continues on until they either reach the end of the listing or press "N" to abort the listing. - "?" or "H"elp ------------- This is the help screen as specified in BRconfig under File Requesting->Help Screen. The path and filename specified there is the file that is shown to the user. A sample screen is included in the distribution archive. This file can include any PCB macros you wish to insert into it and should describe the commands available to the user in different parts of the system. - "Q"uit to BBS ------------- Exits current requesting session. The user is prompted on whether or not they wish to send out their requests, but only if there ARE requests, otherwise the bye screen as specified in BrConfig is shown to the user followed by the delay time as specified in BrConfig that the system "freezes" to wait for the user to see the screen before they are returned to the BBS. 1.6.4 - Other considerations and Setup Options/Tricks --------------------------------------------- Any of the screens specified in BrConfig can have any of the existing PCB @macros@ in them. They will be expanded and shown to the user as they would appear if PCB itself had displayed the file. Please consider using the delay feature very carefully, it is designed to offer alot of control by allowing 1000 counts as a second. We find a setting of about 500 with a 14400 user online is about right but it is totally up to yourself. Also, please remember that online speed is slightly (only slightly) slower when there are alot of messages in the netmail area. This is not a major problem as the messages are only scanned once upon program startup and once afterward for request generations. - Other Systems Requesting Files from Us -------------------------------------- Other sysops can use BRFreq just as well as users. You now have a two level file requesting system. Because the whole system is based using the *.MSG netmail system, BRFreq will honor requests from sysops who have the proper access. BRFreq only discerns on which system the request is from. It will maintain accounting info for these types of requests as well. The format for a request via BRFreq is as follows... To : BRFREQ,<Requested System> Subject : Your TIC password already set up. Message Text : ... REQUEST <FILENAME> <AREANAME> -> Must have keyword REQUEST REQUEST <FILENAME> <AREANAME> -> Must be followed by Area. UPDATE -> Forces new lists from host. LIST <Date> -> Should not be used. --- -> Anything past this is ignored. You should never use the LIST line.It has a datefield calculated which is very hard to describe, and cannot be easily figured out. What is does is basically pass the host system the date of its last update from them. The host then compares the date with the date of its last filebase update and if the number of days exceeds the "List Delay" field value(or 0 for always), then new lists are zipped up and sent back to the requester. This ensure that with every request sent out, the other system is updating you with any new changes to their filebases. By the same token, you can force an update at any time by entering the keyword UPDATE by itself on a line followed by a hard carriage return(Enter); You can also have BRUtil "Get" you a file from another system directly from the DOS prompt. Please read info on BRUtil for more details. You must do a couple of things in order to allow another sysop access to your file areas. First they must have a nodes record in the nodes database.This nodes record should reflect the daily caps as well as the other limits and statistical control options you would like to have for this node. Please include a password they can use as well as setting their security at a rate so that they have enough security to at least see one area. It is wise to set their delay days to zero so that they may request list updates only as they need them. They may also request list updates at any time without adding the lists stats to their account. We considered adding the bytes but opted against it as it would be unwise to debit their accounts for lists. Only files requested will affect their account. As with the regular user requesting system, all behavior is similar so assuming such things as netmail laying around if that node has exceeded their daily limit for another day is something to consider with this end of the system as well. Once they are in the nodes database, you can also have them downlinked (or uplinked) to any echo area so they have total access to your files system. For systems not running PCB, this is the only way to use the requesting system, there is not yet any support in BRFREQ for anything other than PCB. Becaus of this, Additional support was an afterthought prior to release time but we intend to extend support to all BBS types. - System information while using BrFreq ------------------------------------- In future versions of this package, a great deal of attention will be paid to this end of development. We feel at this time that it is VERY rudimentary but functional. This will have to be the time to see what kind of reaction this type of system has and if there is even merit for its continuation. We feel that it is a wonderful idea and hope to have the concept around for a long time. With this in mind, we are hoping to get some feedback as to which way you would like this type of system to go. Ratioed systems, "pay as you play" systems that charge per meg etc. These are all ideas but in implementation quite a different story. With a package of this size it is important to keep overhead down and to keep performance up. Suggestions are welcome. 1.7.0 Using Base Runner ───────────────── Running Base Runner is very flexible to the end user. Any or all of Base Runners features may be disabled leaving (possibly) only the deletions ( not age , just index ) and the filebase updating as the core operation. This is unlikely, however as there would be no point to that. Here we will go over some of the command line parameters that are available to you. You may edit your batch files if you are running on "auto pilot" to reflect and customize your systems requirements and/or work load In no particular order and case insensitive... (This is also similar to the help screen) Only first three letter of the command are required... -Adoptions: Enables New Files Adoptions. -Agedelete: Enables Age Deletions. -All : Assumes all processing without Ega switch. -Announce : Enables Announcements(+) -Bases : Enables FileBase Generation. -Deletions: Enables Deletion Features(Missing Files). -Echos : Enables TIC processing. -Ega : Disables VGA palette manipulation. -Mgr : Enables Area Manager Operations. -Movement : Enables Automated File Movement. -NAs : Enables .No & .NA Processing. -Requests : Enables PCB User Request Processing. -Update : Enables Uplink List Processing. -UpdateNA : Enables importing of new uplink lists. -Uploads : Enables User Upload Processing.(+) -Quiet : Uses stdout only, disables VGA and fancy boxes. -Zic : Enables Inbounce Compressed TICS processing. -? or HELP: Help Screen similiar to this. + = Registered feature These commands may be used in any order and are case insensitive. These may be helpful if you are running Base Runner from a front end and only (perhaps) want to say, run echos but nothing else. This makes overall performance faster because then later on or another time you may then run it in a "complete" processing mode which would then catch up on the overall processing. A couple of examples are as follows... (1.BAT) if exist DONTSCAN.NOW del DONTSCAN.NOW BaseRun /Ann -MGR !req (2.BAT) if exist DONTSCAN.NOW del DONTSCAN.NOW BaseRun -mgr -bas -upd -mov -age -ega (3.BAT) if exist DONTSCAN.NOW del DONTSCAN.NOW BaseRun rem Assumes complete processing (4.BAT) if exist DONTSCAN.NOW del DONTSCAN.NOW BaseRun -All -Ega rem Complete processing without Vga palette manipulation. This rem may be required for some Desqview applications. As you can see, the prefix is not important and you can string as many of these commands togetther as you like. The syntax is short so that many commands may fit onto one command line, which will hopefully offer you the flexibility you will need to get EXACTLY the job you want done. There is a small semaphore file created and deleted each time Base Runner is run. The line to del this file is necessary in case you had a prior power failure or if for some reason that file was left laying around. At the same time, if you are not using any of these types of batch files and for some reason your system has this semaphore file(DONTSCAN.NOW) in the Base Runner directory, you will have to manually delete it before Base Runner will operate properly. You must also have a valid PCB envoironment variable set if you want Base Runner to successfully see the PCB configuration files. You must be in Base Runners home directory to run it or it will not find certain "static" ques that it needs. If you do not use the PCB options of the package, you may ignore this. You must have at least 490K free for Base Runner to run optimally, even though it will run in about 450K. The reason for this is that the archivers and scanners need about 400K and with the foot- print Base Runner leaves in memory, you are already at 450K, but it is best to add an extra 50K for the "static ques". For information on the actual execution and functions performed by Base Runner, please read the section on "What does it do?", 1.1.4. 1.7.1 Area Manager ────════──── Base Runner has a feature which allows your downlinks the abi- lity to automatically perform various database operations via remote(provided they know their password) netmail messages. This is known as using the Area Manager. With this, your downlinks simply enter a fido netmail message addressed to Base Runner on this system, enters their password on the subject line and then puts requests to add or delete echo areas from their current set- up. This is done automatically by Base Runner during its normal operation. There are a few commands available to the downlink. They are as follows... +AREANAME .. adds the area AREANAME. AREANAME .. adds the area AREANAME also. -AREANAME .. removes the area AREANAME. %RESEND<File> .. Please see below for explanation. %ALL .. Adds all available areas. %LIST .. Requests a list of all available areas. %QUERY .. Requests a list of all connected areas. %UNLINKED .. Requests a list of all unlinked available areas. %LINKED .. Requests a list of all linked areas. %PASSWORD .. Changes the current password for that node. %ARCHIVER <type>.. Changes default archiver type to type. %TICMODE <mode> .. Changes Ticmode to mode. %HELP .. A file called FILEMGR.HLP is put into a netmail message and posted back to the requesting sysop. This file can contain whatever you like and can be edited with any plain vanilla text editor. There is also a special kind of '%' command available to the requesting node. This is the %RESEND macro and is basically just what it says. Sometimes, you may find that you no longer have a file you really wanted to keep but for some reason(age deletes etc.) you would like to get it again. You may simply use the resend macro along with a filename on the same line to get the file along with the original TIC it came with. The TIC will help you to import it normally when it comes. A note should be made here that when the file comes back through, it does *not* increment any of your file/byte counts, including daily counts as it is assumed you have already received that file, therefore the value increment would reflect an incorrect figure. As well as as that command you also have %TICMODE and %ARCHIVER available to you. TICMODE can be any one of these 5 settings... - FilesOnly - Base Runner will send out files with no TIC. - FilesandTics - Base Runner will send out both files and TICS. - PackTics - Packs up TIC files but attaches files regularily. - PackFilesOnly - Packs up files with no TIC attach. - PackBoth - Packs both TICs and Files into one archive. All one word, case insensitive(except the TICMODE command). Also included is ARCHIVER, which can be any 3 character string as the new archiver type. Please be sure that the system supports type, for example "ZIP", "ARJ", "PAK" etc... This system offers a powerful way of managing echo areas with the greatest of ease and use. Every activity is logged and full security checking is performed to ensure that the node is indeed qualified to make such a request. Replies are sent back to the originating node for all area manager requests. All request text past a "---" , tear line, beginning on the left column of the text, is ignored and is considered comment and/or personal text and not to be processed any further on down the file. If a nodes request reply is longer than 400 lines, a new continuation message is generated and the list continues on that message. This may go on for as long as it takes to satisfy the area manager request. 1.7.2 - What Went Wrong? ---------------- Below is a list of commonly asked questions to aid in solving some problems you have be having. Of course support is readily available. Please read below for more details on how to obtain support directly from CompuData Systems. Q. - When I try to run BRCONFIG, all I see is the intro banner and then I am dropped back into DOS. Why won't the config program run? A. - You might have a corrupt resource file. This is the file named BRCONFIG.RC. It is used primarily for the config but it will be used by all programs soon. Q. - I have a file area set to move files after 15 days but they are never moved, in fact, they are not anywhere at all! A. - Do you have age deletions set for that area with an age set up less than the movement days? If so, make sure deletions are set up later than movement (also good for cleanup) or disable them altogether by setting the number of days to zero. Q. - When running the configuration program, all I ever get to see is "PCBOARD.DAT file not found!". A. - You have installed your system as a PCB system which means that the config program now looks for your PCB envoironment variable and reads your PCB configuration files to get info about your system to make your work easier for you. A good example of this is the Import File Areas function in the file areas manager, it scans the areas not currently in your database and shows them to you and allows you to pick the areas you would like to configure. Q. - I have the PCB end of things set up properly, but I still can't run the config program. A. - Do you run a network? If so, do you use the proper DOS pathname or do you use the networks system for the envoir- onment variables? Base Runner requires that you make your network be able to read regualar DOS pathnames such as.. D:\PCB instead of the common NODE1\\C-DRIVE\\PCB. The second example will not work and Brconfig will bark up if confronted with these pathnames. Q. - I have a file that just won't move, no matter what! I have file movement for that area set up and it is long overdue! A. - Is the file area set up for downlinking originals or modif- ied files? If modified files, it could be that the file is still frozen. If a file is echoed directly from one of your filebases, it is temporarily "frozen" while it gets mailed out to your downlinks. Then you must run BRUTIL NOKILL to clean the flags up on these files. Then you can see that the movement operations will again kick in. Q. - Base Runner seems to always want to delete files from the outbound that aren't even sent yet! A. - You could be set up for PCB netmail. If so, it is important for us to know which netmail you use, 15.21 or later. They are very different in the way the FIDOQUE.DAT file is stored so you must have the proper one set for your PCB system or you will have problems reading this file and might lose some files. Q. - In file movement I see alot of files in one area with many different owners, why are they not all the same name? A. - Some of them may have just got into that area. They are "in transit" so to speak. They will get move when they have been in that area the specified number of days. Another thing to watch out for is "dead" links in the chain. For example, NEWUP moves to 1-30 after 1 day and then after 30 more days they go to 30-60, then to OFFLINE. You think that it is supposed to go to OFFLINE directly but first it has to go to this areas destination. The problem here is that the link between 1-30 and OFFLINE is broken because of the link 30-60. If 30-60 is not set up to properly move to another area(the OFFLINE area must be in the path somewhere or the file will continually move), or it is not set up at all for movements, the files will just sit in 30-60 and not go anywhere, so OFFLINE never sees the files. Just follow the area chain down to the final destination point and make sure all links are set up properly. 1.7.3 Converting from Other Formats (Convert.exe) ─────────────────────────────────────────── Base Runner offers a small utility that you may only ever need to run once, hence the reason for it being all by itself. It is call CONVERT.EXE and its sole purpose is to convert data files from other programs to Base Runners format or at least as close as we can get. It is sometimes hard to get as much information as we need, but you will have as much information as is possible. The reason for this is that Base Runner is much more complex and stores more information critical to its operation than most other programs so depending on what you are converting from, some of the information will still have to be manually inputted. Support includes ALLFIX. To invoke this program, simply type the program name and a help screen will pop up with the available types. This list is always growing and these programs constantly go through updating so it would not be wise to try to pin down just what is done. We will endeavor to keep up to the many versions. When converting from other formats, you must make sure you copy the appropriate setup files into Base Runners directory before you proceed. This ensures the integrity of your original data while allowing Base Runner its home directory (which it uses to calculate home paths as defaults, etc...) to set itself up in the most complete way. As an example, for Allfix, copy all the *.FIX files into Base Runners directory and then from that home dir, just type CONVERT ALLFIX and it will take care of all the echo areas, folders(groups), nodes, system info and initializes a new duplicate base. We would like to make note of the fact that these programs may change their configuration at a moments notice. We endeavor to keep up with any changes we know about. You may, however, not have a current Convert.Exe because the format you are converting from has changed since the last update of the Convert program. If this is the case, we probably already have a current copy available. You can contact any one of the support sites to obtain the most current copy. If we haven't yet dealt with the current version you are running, we would appreciate any info on the changes you might know about and/or any development text that may be available. We can usually have the Convert program update within a day or two of receiving such info. Please read section on support for more details on obtaining a current copy. 1.7.4 What You Get for Registering ──────────────────────────── Base Runner comes fully functional right out of the box! There are, however, a few added features that greatly enhance the functionality of Base Runner which you may be interested in that comes with registering the software. You are not expected to register the software if you do not need access to the registered features, but we would certainly not argue with you if you did... Some of these features are... 1 - Automatic Uplink List Maintenance. Uplink lists are automatically imported into the system as they come in. 2 - Upload Processing. Process and import User Uploads directly into the filebases. 3 - New File Announcements. Have Base Runner post messages into any message base. 4 - Access to the full command line version of the Utility Program. Most of what that program is capable of is included in the full screen interactive version but there are a few differences. These are History(generate History reports), Get (gets a file from any node from command line), Master(builds a master list of specified file areas). All of the others are still available in the full screen version. 5 - Auto-Add Echo areas. This feature will automatically create areas on the fly! 6 - Archive Comment support. This is the header comment you can insert into archives. Full macro support is also included so that you may template any style of comment with up to the second information right in the comment text. 7 - .NA and .NO File area description processing. You become a supported user and can feel free to count on support any time you need it. You have access to the support sites for support as well as receiving a discount of %10 on your next CompuData purchase. Please consult PRODUCTS.DOC for more details on the continually growing line of communications software offered by CompuData Systems. 1.7.5 Errorlevels Returned by Base Runner ─────────────────────────────────── Following is a list of returned errorlevels and what they mean.... 1 - Configuration File SYSINFO.DAT file not found. 2 - Invalid or missing Work directory. 3 - Invalid or missing Main Filebase directory. 4 - Invalid or missing Filebase Index directory. 5 - Invalid or missing FileBase Header directory. 6 - Invalid or missing FileBase Text directory. 7 - No node addresses were specified in config. 8 - Invalid or missing Inbound directory. 9 - Invalid or missing Netmail directory. 10 - Invalid or missing Header directory. 11 - Semaphore file found, active on another node. 12 - Invalid or missing Embedded Archive directory. 1.7.6 Why Use Base Runner instead of the competition? ─────────────────────────────────────────────── There are many TIC processors out there available. We won't go into all the various types but will zero in on a couple of them to show you just why you should use Base Runner. The ones we will pay the most attention to are Allfix and DW_TIC (or TIC2PCB). Please note that Base Runner has all of their features as well as the ones below plus any new ones that have and will be added after the printing of this document. - Speed. Base Runner is written in Assembler and C++ programming language. The others are written in Turbo Pascal. Pascal, while a fine language, is just not as fast in execution as assembler and C++ objects. Also, Pascal does not store high enough numbers, so certain statistical information must be kept to small numbers. This is a bit of a hinderance for some things so you will find these authors omitting certain statistical info. - Features. Base Runner is the only program of its kind. It is the only program that has such a file request system available to users as it does. NO other system offers users availability to other BBS file areas so directly as BRFREQ does. Allfix has a system where sysops or perhaps even users may scan for files on other BBS's, but then what? Users cannot then request or gain access to those systems unless they wish to call them directly, go through their new user procedure and then perhaps gaining access to these files. If then, this feature is only available to the sysop who wishes to file request these files directly, no apparent gain is extended to the user. Who do we run our BBS's for, ourselves or our users? Base Runner breaks down that wall, allowing your users DIRECT access to configured systems, taking care of all aspects of moving the files from their systems to yours, even announcing, upon arrival, these files so that users may then download them. And this is only one of Base Runners features... Others include ... 1. Up to 10 virus scanners. 2. Unlimited echo areas(Allfix has only 2048) 3. Unlimited nodes(Allfix has only 1024) 4. Unlimited downlinks(Allfix has only 256) 5. Up to 50 Aka's(Allfix has only 20) 6. Seperate file and echo areas(Allfix requires you to duplicate a single file area for each echo area you have, possibly requiring you to change MANY echo areas in order to alter configuration for one single file area... lame, very lame). 7. 3 different video modes of operation(Allfix - 1). 8. Up to 15 uplink lists per node(Allfix - 20 total). 9. Send file to any node anywhere, anytime. 10. Get a file from any system anytime, anywhere. 11. Full featured Util program with 2 video modes as well as command line operation for use with events, batches etc. And this is only what I can think of off the top of my head(that I can verify), there are many many others. - Specialization. Base Runner does not try to be all things to all people. We realize that BBS programs are very diverse. We therefore only support both PCB and FILES.BBS systems directly. We do not try to support 20-30 programs. This would be, in our opinion, total overkill. That way you get some features per system but never a complete system to deal with YOUR BBS. Pascal having its own limitations, Allfix is tapped out on data space, more features at this point will greatly influence its reliability factor. We cannot make this claim in the case of DW_TIC as it only supports PCB at this time(this may change, however). - Automated File Movement. Either of the other two support this feature as they are just not designed to do such things. In Allfixs' case, because many echo areas can include the same file area, under its current design, it cannot even consider direct file area support such as this, not to mention the overhead and extra data it is storing to duplicate a single file area into many echo areas. - Seperate BBS and TIC layers(or file and echo areas). One of the most inventive design implementations of Base Runner is its use of seperate file(BBS) and echo(TIC) areas. Why would we want to duplicate data in all those echo areas when all we want to do is to point many echo areas to one file area? Why didn't Allfix think of this? We don't care, we only know that if you want to change one file area, you change only one area, not have to hunt down all these echos that may point to the same file area to make your changes. Plus we do not have to memorize all these duplicate areas. We do not know how DW_TIC handles this. Some people claim to be confused by our design but once you grasp the obvious concept of these seperate layers, you will wonder why it was ever designed any different. - Direct configuration using an easy to use config program. DW_TIC requires (as of the printing of this document) you to manually edit a text file as its configuration system, with no help systems, no pick list dialogs... nothing. We did things this way 15 years ago when most of us programmers did not concieve of the idea to do it any differently. Base Runner provides an easy to use, flexible configuration program which allows easy pick list dialogs for situations when you don't know which BBS area you wish to use(for example) as well as a full help system anywhere in the program by simply pressing F1. This is not a feature, in our opinion, as much as it is a necessity. When we learned that our competitors use this system, we honestly could not believe our ears. - Age deletions. No other system has this feature. Base Runner can automatically delete files that are older than a certain age. - Empty base cleanup. Base Runner will also search through your BBS areas and delete any filebase entries if no file exists on disk to match that file, keeping your file areas clean. This is totally configurable on an area per area basis, of course! Neither Allfix or DW_TIC have this feature. - Filebase Editor. Easy to use editor with very powerful features, none of which are crippled. These include 2-way file id insertion/extraction, abandon file (delete only filebase entry), delete, view archive, information stats on current area, move, copy etc. This is a full feature system so that you really have no need for such programs as PcbFiler. Allfix nor DW_TIC provide such a program nor likely ever will. - Online door for your users(PCB only). This is as we mentioned above, but has an online chat module plus features to hang up on user, change security and lockout user any time you wish. It also provides the user with commands such as "login to BBS", "Files", "Areas", "Flag for request", "Batch editor", "Logoff BBS" and "Exit to BBS" as well as many more being constantly added. This system will eventually be adapted for other BBS types, but only BBS's that support the FILES.BBS format or that fall into our area of support. Neither Allfix or DW_TIC offer this feature. As you see, these are only but a few of the extra features provided by Base Runner. Add that it is not crippled nor has "evaluation" periods after which it just refuses to run. Why would we let you get your whole system set up and then just yank the cord on you? Kind of violent if you as us... ;) You are free to run Base Runner as long as you wish free of charge. Of course we have a few features(None of which were mentioned here), that you get when registering(as well as free updates and constant contact), but they are actually inconsequential when compared to the overall scope of operation of our competitors. 1.8.0 - Strategy ──────── This section is provided to give you some ideas on good ways to implement Base Runner. There are such a myriad of ways to run it, but we have run into some during testing we thought we would share with you. They are laid out in as easy to read form as possible. We hope this will give you an idea of just how powerful this package can be and to help you think in ways we have not even yet imagined possible. If you have a unique setup you do not see here, please let us know, we will put it here for others to catch. - Simple Three Tier System ------------------------ Inbound | ---------------------------------------------- | | | | Games1 Games2 NODELIST Os2 | | | | 2 days week 28 days 1 day | | | | --------------------------------------------- | Offline(eg. Tape Backup) - Time is of the Essence ---------------------- Inbound | 0-7 days | Move after 7 days | 7-14 days | Move after 14 days(set to move "Home") | ---------------------------------------------- | | | | Games1 Games2 NODELIST Os2 | | | | --------------------------------------------- | Offline(moves nowhere) - A variation on that Theme ------------------------- Inbound | 0-7 days | Move after 7 days | 7-14 days | Move after 14 days | ---------------------------------------------- | | | | Games1 Games2 NODELIST Os2 | | | | --------------- ------------- | | | Inbound OtherNet | | | ----------------------------- | | | | | Net Stuff O.Systems Request | | | "Home" | -------------- (no move) | | ----------Offline------ (both nets files end up Offline) 1.8.1 - More Points Regarding File Movement ----------------------------------- Please remember a few points when dealing with file movement. These will help you to more fully understand the concept behind it. - Once files have been imported by TIC, the echo areas are no longer considered. They are only involved as far as to setup up an initial file areaname and an owner file areaname. After that, file area configuration TOTALLY handles file movement, including links. - At any time, a file area might use the keywords HOME or NOWHERE. HOME means that all files that are moved from this area are automatically move to their HOME or owned area. This ownership is first established by the field in echo areas, but may also be edited using BREDIT. NOWHERE means that the file area does not support movement of any kind. You may also leave this area blank or set days to 0 for the same effect. - Link days represent days as they stand from the date of movement and not the file date. Hence the file date is NOT altered during movement and all dates are still kept internal. - Once a file is home, it stays there. This is ascertained by matching the owner name to the area name. Even if more files come in and there are movement characteristics setup for this area that might include linking to another area, once a file owner name matches its current file areaname, it is considered out of bounds to movement. This may be edited or overriden with BREDIT manually , of course. - Make use of the "Trails" feature in file areas. This helps in debugging your setup and allows you to view your current file movement trails, showing you all areas linked BELOW this one right to the end. Up to 700 trails can be shown at any one time. - Remember that if you wish to leave a file in an area longer or even shorter than it normally would, you may edit its date using BREdit. Be sure to edit the Arrival Date and not the file date. - More on the last one, Base Runner keeps two dates recorded for each file. Each time a file successfully moves to an area the arrival date is reset to the day it is moved. Then when the days are met from that recorded date, the file gets moved. The actual file date on disk and in your database stays the same. With this in mind, it is possible to have a file that is years old but still be involved in a movement cycle. - Unlike some other movement processors, Base Runner does not rely on any more than a couple of fields edited once in the config program to set up characteristics. We do not require you to know filenames or wildcards when files are being moved. You only need to know the area name to move the file to and the number of days in which to move it. 1.8.2 - A Couple of Tricks - not for the faint at heart ;( -------------------------------------------------- Automatically have Base Runner maintain your inbound directory by setting up a file area that points to that directory and have auto adoptions(orphans) set to "Y". Since adoptions are done after any other file importation, it can be assumed that all files are now processed from your inbound. If there are any "strays" hanging around, they can then be adopted and if their movement day is set low, they are moved out of that area. This ensures total maintenance on your inbound directory. You will have, of course, all the stray files to edit or delete or move etc., so that even files that come in without TICs or just any stray attach files come in, you have them adopted and in your system. Another trick feature of this type of system is to create an echo area record to be used as a clone for the auto-adding features of the areamgr. In this record, the trick is to put any nodes you wish to have ALL areas added by the uplink attached to this area. For example, BOSS sends me files and BOSS is set up with a TEMPLATE clone area that has END as a downlink in it. BOSS sends me an area I do not recognize so I auto add with the new TEMPLATE area. Automatically that node is connected to this newly created area. This is a nice way of allowing downlinks to get "Whatever new area comes in" from you. You can have Base Runner automatically hatch out your new master lists. Simply set up a new echo area and make sure the correct systems are connected to this area. Then every time you run BRUTIL HISTORY(or any of the reports operations) you can have your batch file then run HATCH on the master list file into the newly created area and all the downlinks in that area receive the file and that area records the files and Kilobytes hatched. 1.9.0 Support ─────═══───── Support is available from Alpha City BBS . We have a support conference on that system that is directly tied to us.You may send netmail (routed ONLY as we are private)to 1:229/2 to gain direct access to CompuData The phone number for the support BBS, Alpha City BBS is (905)579 1502 any time of the day. Just join the CompuData Message conference or the CompuData file area to see what is the latest on our product line.We have a continually growing line of communic- ations products based for the PCB envoironment as well as many uti- lities sysops and users alike would enjoy.All support is handled by Steve Tupy of CompuData,so address any questions and/or messages to him directly to gain the fastest access. There is also an echomail conference called COMPUDATA available from any of the above sites. Of course you may also call us anytime for orders or voice support at (905)721-8944. Please consult file REGISTER.DOC for registration information and support. Please register if you are going to use this product, it makes the product better all around. Please have a look also at a file called PRODUCTS.DOC. It lists all the available products CompuData currently has in release. Also, we are always looking for beta testers so if you are interested in any of these packages let us know, we are always happy to listen! 2.0.0 Lets Hear it for our Beta Team! ─────────────────────────────── Good things come from hard work and Base Runner is no exception. CompuData Systems would like to acknowledge the following people for their excellent contributions. These people worked very hard and are the people behind the lines but does not make them any less a part of CompuData Systems and any success that it may enjoy as a result of that work. Base Runners Beta Team ---------------------- Ron Provost 1:229/401.0 Graham Pearson 1:2285/60.0 Joel Fiszman 1:250/669.0 John Morse 1:229/426.0 David Bate 1:229/618.0 Andrew Adams 1:229/214.0 CompuData would like to also acknowledge the following people for their ideas and suggestions and any other help that they have offered. Ken Wilson 1:12/12.0 Rick Johnston 1:229/2.0 Fred German 1:229/124.0 Also, special thanks to Rick Johnston & Ron Provost for all the late night hours of brainstorming ideas and concepts. We came up with alot of interesting things, most of which you will see all over this package. David Bate has done a great job on the extra screens. We include all 8 of them for your perusal, if only for quantity. These are all the BRFreq screens with the "BR" as the first letters of the name. We think you will like them very much. There is never too much that can be said about the efforts and determination of these people. During a time when it is hard to get anyone to even look at a package when so many are out there, these people all took great interest and are *very* much involved in the overall effort! 2.0.1 Files in the distribution archive --------------------------------- If you did not receive exactly these files in the distribution archive, we will not gaurantee its validity. Please see section on support sites to get the latest CompuData Systems releases. Getting the packages from any of those sites will gaurantee you a valid copy. Accept no substitutes! ;) Executable Files ---------------- BASERUN.EXE - Main Program, processes all incomming files, requests, deletions,file movement,age deletions, adoption,auto area create,auto node create, file manager, imports uploads, regenerates DIRs,CRC, Dupes,Virus Scan,Comments, File id,Add file(s), Delete file(s),Announcements. This file is su- bject to change with new additions. BRCONFIG.EXE - Configuration Program, allows easy interface to setting up and running Base Runner, adopting PCB bases etc. BREDIT.EXE - Main Filebase editor with many added features. File id,hatching, add files, copy, move, delete, add,edit, datestamp,abandon,view etc. BRUTIL.EXE - Utility program. Can be run in interactive mode or command line mode. Pack, deletes, indexes, hatching, notifying, dupetrim, duplicates, un- linking,init bases etc. BRFREQ.EXE - File requesting door for your users. Must be installed properly via PcBoard. INSTALL.EXE - Installation program. CONVERT.EXE - Conversion program will convert existing programs config files over to a Base Runner format. Sample Files ------------ MSG.TXT - Sample message text to insert for announcements. Includes some macros which are supported. MAING - Ansi of main menu for BRFREQ. Very simple. BRMAIN - Another sample, a little brighter. INTROG - Logo or intro screen for BRFREQ. BRINTRO - Yet another Intro screen. BYEG - Screen shown to users upon exiting BRFreq. BRBYE - Also screen for exiting BRFreq. BRHELP - Help screen for activate of "H"elp command. BRFREQ.HLP - Just another version of the same screen. COMMENT.TXT - Text for comments with full macro support. FOOTER.PCB - Example footer for insertion in DIR files. These files should be kept in the HEADERS directory. HEADER.PCB - Example header for insertion in DIR files. These files should be kept in the header directory. BRFREQ - Sample batch file for BrFreq for use with PcBoard. RUNBR.BAT - Sample batch file for running Base Runner. Help System Files ----------------- BASERUN.HLP - Main help text file, indexed, do NOT modify. BASERUN.IDX - Index for BASERUN.HLP. Must be in home directory. BRCONFIG.RC - Resource file containing menus and string tables. Documentation Files ------------------- PRODUCTS.DOC - Available CompuData products as of the compila- tion of this document. It grows all the time. REGISTER.DOC - Registration information. Here you will also find a printable registration form you may send in with your registration payment. BASERUN.DOC - This main documentation and reference point for Base Runner(this file). README.DOC - Introduction and installation notes. 2.0.2 Database Files Maintained by Base Runner ---------------------------------------- FAREAS.DAT - File areas database. FECHO.DAT - Echo areas database. NODES.DAT - Nodes database. HISTORY.DAT - History and User Cue database. ARCHIVE.DAT - Archiver definitions. FOLDERS.DAT - Folders database(or groups). SYSINFO.DAT - Main system configuration and paths. DIRWRITE.$$$ - List of areanames in PCBDIR/FILES.BBS Queue. End of Document.